Hi, would an 'add-pois-to-lines' option (similar to the new 'add-pois-to-areas') make sense ? I tried to create an maxspeed layer to show the maxspeeds using the highway-shields, but this didn't work well (because garmin shows the shields only for some roads). With the suggested add-pois-to-lines it would be possible to show little maxspeed icons (30) (50) etc. on the roads or to show incline-icons on roads which have an incline=* tag. Chris
This would also be a great feature to show route-signs (hiking, cycling etc.) But it would be overkill, to create such a node for each way. Henning
It would be nice to have such feature and I agree it may clutter the map, but you can make the poi almost invisible with the typ file. Now I need to add a poi amenity=ferry_terminal on a route=ferry to show additional information, like ferry schedules, or add another line on top with this info. By adding a (almost invisible) poi you can add this info better, for instance a very small red x for time restrictions on a road, access=no, motor_vehicle=destination etc or a marking for a hiking or cycling route
Am 26.10.2011 10:20, schrieb Minko:
It would be nice to have such feature and I agree it may clutter the map, but you can make the poi almost invisible with the typ file. Now I need to add a poi amenity=ferry_terminal on a route=ferry to show additional information, like ferry schedules, or add another line on top with this info. By adding a (almost invisible) poi you can add this info better, for instance a very small red x for time restrictions on a road, access=no, motor_vehicle=destination etc or a marking for a hiking or cycling route For all this Information you can put a transparent line over (or under) the highway... MapSource will show every name of each line. I'm not sure how devices handle this. Therefore it could also be useful to write different names in address-index and on the object. Is this possible?
Multiple lines are handled very well in Mapsource and Basecamp, see http://img197.imageshack.us/img197/208/veerpontje.jpg On the device only one line name is shown, usually the streetname (in this case it's a bike route name) If you zoom out, and this line disappears, another line with info is shown: http://img845.imageshack.us/img845/8794/324.png This line I use for opening_hours tag on ferry lines. It is only visible if you zoom out and no bike routes are on the same route=ferry, like in the first example. Question is, will this be possible with a pois-to-lines option and how? With road-name-pois only one parameter is put on the lines, the road name. We want to use it for different other tags (access, opening_hours, etc) but is this possible?
Moin, I really would like to have an add-pois-to-lines feature. Henning Scholland schrieb am 26.10.2011 00:24:
This would also be a great feature to show route-signs (hiking, cycling etc.)
But it would be overkill, to create such a node for each way.
Actually it wouldn't be enough, to create one node for each way, for route signs you would need multiply symbols for each way. A first version could be, to copy the way tags (already inherited from a relation) to each node of the way. A nicer version would be, to leave out some nodes, when they are to close together. Another use might require to mark the first and/or the last node of a way with a specific icon. Gruss Torsten
Of course you're right. There should be more Nodes in a fix distance to each other like MapComposer did it. My intention was, that the user should be able to control for which ways these nodes were created. E.g. if I just want to display maxspeed-signs, these nodes should only be created if the way has a maxspeed-tagg. Henning
And just remember that if you ever use that option, maps will be incompatible (meaning frequent BSOD) on all old Garmin GPS like Vista HCx and Co - just like the current poi-adresses option crashes the POI search (in comparison to it not being used) and often causes BSODs (for me like 0.5 times daily). Garmin GPS are not suited for POI overload like it is happening with such options. It's just a really really dirty hack, to implement something that was not intended to be shown. The NT map format does have possibilities for such information - problem is that we have absolutely no clues about it. So don't expect Garmin will remotely improve here, as they already have a format that would be suitable for such information. On 26.10.2011 17:37, Henning Scholland wrote:
Of course you're right. There should be more Nodes in a fix distance to each other like MapComposer did it.
My intention was, that the user should be able to control for which ways these nodes were created. E.g. if I just want to display maxspeed-signs, these nodes should only be created if the way has a maxspeed-tagg.
Henning
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, I am very undecided if this option is reasonable or not. But it's easy to implement so I decided to let you test and decide yourself if it makes sense or not. Attached patch does the trick. I haven't added an option yet so it works if add-pois-to-areas is set. For each line all points plus the middle point are added as POIs (tagged different with mkgmap:line2poitype). For lines each POI is tagged additionally with the following tags: mkgmap:line2poi=true mkgmap:line2poitype=start|end|inner|mid Have fun! WanMil
Hi, would an 'add-pois-to-lines' option (similar to the new 'add-pois-to-areas') make sense ?
I tried to create an maxspeed layer to show the maxspeeds using the highway-shields, but this didn't work well (because garmin shows the shields only for some roads).
With the suggested add-pois-to-lines it would be possible to show little maxspeed icons (30) (50) etc. on the roads or to show incline-icons on roads which have an incline=* tag.
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
HI, thanks for fast implementing, but I have trouble applying this patch to trunk: patch -p0 < lines2poi_v1.patch (Stripping trailing CRs from patch.) patching file Areas2POIHook.java Hunk #1 FAILED at 52. Hunk #2 FAILED at 166. Hunk #3 FAILED at 236. 3 out of 3 hunks FAILED -- saving rejects to file Areas2POIHook.java.rej Chris
On Fri, Oct 28, 2011 at 09:46:07AM +0200, Chris66 wrote:
thanks for fast implementing, but I have trouble applying this patch to trunk:
patch -p0 < lines2poi_v1.patch (Stripping trailing CRs from patch.)
Just a quick guess without looking at the patch: did you try patch -lp0 to ignore white space differences? Marko
Am 28.10.2011 10:04, schrieb Marko Mäkelä:
On Fri, Oct 28, 2011 at 09:46:07AM +0200, Chris66 wrote:
thanks for fast implementing, but I have trouble applying this patch to trunk:
patch -p0 < lines2poi_v1.patch (Stripping trailing CRs from patch.)
Just a quick guess without looking at the patch: did you try patch -lp0 to ignore white space differences?
Marko
Hi, I will try this. What's the original file size of the patch? After saving from email it has 6452 Bytes. Chris
Am 28.10.2011 10:40, schrieb Chris66:
Just a quick guess without looking at the patch: did you try patch -lp0 to ignore white space differences?
I will try this.
This did not help. OS: Ubuntu 11.04 Filesize of the unpatched Area2PoiHook.java : 7890 Chris
Hi
Just a quick guess without looking at the patch: did you try patch -lp0 to ignore white space differences?
It doesn't apply for me either. This is because the existing file has DOS line endings, whereas the patch has UNIX line-endings. If you add a CR (^M) to every line *except* for the diff control lines then it will apply. I've attached the result. ..Steve
Am 28.10.2011 13:12, schrieb Steve Ratcliffe:
It doesn't apply for me either. This is because the existing file has DOS line endings, whereas the patch has UNIX line-endings. If you add a CR (^M) to every line *except* for the diff control lines then it will apply.
Hi, thanks, another solution is dos2unix the java and the patch file before applying. Chris
Hi, what did I wrong? I used the commands from the mkgmap dev wiki: ant clean ant dist copied the dist/mkgmap.jar over my regular mkgmap.jar. File size : 1.738.428 Bytes Error at line 1, col 1 Error at line 1, col 1 Bad file format: c:\apps\mymap\osmsplit\10000001.osm.pbf Error parsing file Bad file format: c:\apps\mymap\osmsplit\10000002.osm.pbf Error parsing file Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:426) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:130) Chris
Am 27.10.2011 20:51, schrieb WanMil:
I am very undecided if this option is reasonable or not.
Yes, I think it's usefull, because you can do some tricks you can not do without this option. So, first Test : error file shows that POIs have been created : SCHWERWIEGEND (Areas2POIHook): c:\apps\mymap\osmsplit\data.osm: 1991 POIs from single areas created SCHWERWIEGEND (Areas2POIHook): c:\apps\mymap\osmsplit\data.osm: 19040 POIs from lines created SCHWERWIEGEND (Areas2POIHook): c:\apps\mymap\osmsplit\data.osm: 33 POIs from multipolygons created But I don't see the icons on my map. I added the lines highway=* & (hgv=no | hgv=destination) [0x7005 resolution 20] highway=* & (maxheight < 4) [0x7005 resolution 20] highway=* & (maxweight < 12) [0x7005 resolution 20] to the points file and created an icon "hgv no" with the Typ Editor. Chris
Am 28.10.2011 18:09, schrieb Torsten Leistikow:
So it works.
Can you please provide your mkgmap.jar file? I do not have a development environment for mkgmap at the moment but would like to try out the patch.
Hi Torsten, I can do that, but it won't work with pbf files, because I don't know how to build with pbf support (see my post of 16:55). Screenshot: <http://up.picr.de/8608466vfp.png> Showing the maxheight as popup info. Chris
I have uploaded it to http://files.mkgmap.org.uk/detail/39 WanMil
Am 28.10.2011 18:09, schrieb Torsten Leistikow:
So it works.
Can you please provide your mkgmap.jar file? I do not have a development environment for mkgmap at the moment but would like to try out the patch.
Hi Torsten,
I can do that, but it won't work with pbf files, because I don't know how to build with pbf support (see my post of 16:55).
Screenshot:
<http://up.picr.de/8608466vfp.png> Showing the maxheight as popup info.
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Moin, I tried the patch and I think the add-pois-to-lines option is quite usefull. Although I have some issues with the actual implementation. 1. Tags originating from the line are correctly transfered to the points (e.g. incline=* on the highway can be used to generate symbols at the highway nodes). But if the tags are originating from a relation and only generated on the way during the relation processing by the apply command, then this tags ar enot transfered to the points. So it is not possible to create POIs at all nodes belonging to ways belonging to a route. 2. I think it should be possible to differentiate whether a single tag belongs really to this node or is create by the add-pois-to-lines processing. For example: We have a line highway=primary and this line contains a node marked with highway=trafic_signals. With the actual implementation the node would only have one highway-Tag, the other on gets lost. Perhaps it would be better, to not only transfer the tags from the line to the nodes, but add a prefix to the keys, e.g. mkgmap:line2poi:highway=primary 3. I think the tag mkgmap:line2poi=true is not required, since all nodes are marked with mkgmap:line2poitype=* anyway. 4. A single node can be member of multiple lines. E.g. a highway crossing can be the inner node of one line and also the start node of another line. Will this create any problems? With my suggestion 2 you could at least differentiate, when the line2poitype is different, but if the crossing is an inner node of two lines, you are still kind of lost. Gruss Torsten
Moin,
I tried the patch and I think the add-pois-to-lines option is quite usefull.
Although I have some issues with the actual implementation.
1. Tags originating from the line are correctly transfered to the points (e.g. incline=* on the highway can be used to generate symbols at the highway nodes). But if the tags are originating from a relation and only generated on the way during the relation processing by the apply command, then this tags ar enot transfered to the points. So it is not possible to create POIs at all nodes belonging to ways belonging to a route.
The relation style is applied after the pois-to-lines. Maybe this could be changed but I don't know about side effects.
2. I think it should be possible to differentiate whether a single tag belongs really to this node or is create by the add-pois-to-lines processing. For example: We have a line highway=primary and this line contains a node marked with highway=trafic_signals. With the actual implementation the node would only have one highway-Tag, the other on gets lost. Perhaps it would be better, to not only transfer the tags from the line to the nodes, but add a prefix to the keys, e.g. mkgmap:line2poi:highway=primary
It is either possible to create completely new nodes (this is implemented) or to add the tags from the line to the existing nodes (then you get a "merge" problem if both line and node contains the same tag with different values). I decided to implement the first solution which is much easier. You report that the information of original node is lost. I don't think so. But it is possible that somewhere else in the mkgmap code or in the Garmin software there is a limitation that there can be no more than one POI per coordinate. In this case the first (or last) POI created wins and the other is lost. This is not a problem of the pois-to-lines feature.
3. I think the tag mkgmap:line2poi=true is not required, since all nodes are marked with mkgmap:line2poitype=* anyway.
That's true. I wanted to implement it similar to the add-pois-to-areas.
4. A single node can be member of multiple lines. E.g. a highway crossing can be the inner node of one line and also the start node of another line. Will this create any problems? With my suggestion 2 you could at least differentiate, when the line2poitype is different, but if the crossing is an inner node of two lines, you are still kind of lost.
You can invent serval extra mkgmap tags to solve this (e.g. mkgmap:line2poi:1:highway=secondary, mkgmap:line2poi:2:highway=tertiary for a crossroads of secondary and tertiary). But does that really help? And more important: Will anyone understand this in 2 months? I don't think so. WanMil
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Moin, WanMil schrieb am 30.10.2011 14:10:
The relation style is applied after the pois-to-lines. Maybe this could be changed but I don't know about side effects.
That is bad news, because using the add-pois-to-line options for marking hiking routes is one of the uses I had in mind.
It is either possible to create completely new nodes (this is implemented) or to add the tags from the line to the existing nodes (then you get a "merge" problem if both line and node contains the same tag with different values). I decided to implement the first solution which is much easier.
Ah. That's the better solution and should also solve my issue No.4, where a single node is member in multiple lines. So you will have multiple nodes on the same coordinates: - 1 node with all the original tags from this node - 1 node for each line, with the tags mkgmap:line2poi=true, mkgmap:line2poitype=* and all the tags from this line
You report that the information of original node is lost. I don't think so.
I can confirm, that the information from the original node is not lost. I feared, that in case of a conflict the information from the line would get lost. But know I understand your implementation better. So beside the relation topic I am happy with your patch, even with this limitation I think it is worthwhile extension of the mkgmap possibilities. Thanks. Gruss Torsten
I have modified the patch by the following things: 1. The relation style is now applied before the POIs are added 2. You must now set the add-pois-to-lines option to enable the POI generation 3. Some basic help text Running the relation style earlier is a bit contrary to the mkgmap design but it seems to work (I don't know if processing of mp files is affected by this?). Anyhow the relation style is a bit different from the other style files as no garmin objects are created. So I think I can live with it. @Steve: What do you think? I think you have created big parts of the style system and so you should be happy with that change. I have also uploaded a compiled version of the patch: http://files.mkgmap.org.uk/detail/40 Have fun! WanMil
Hi,
I am very undecided if this option is reasonable or not.
But it's easy to implement so I decided to let you test and decide yourself if it makes sense or not.
Attached patch does the trick. I haven't added an option yet so it works if add-pois-to-areas is set. For each line all points plus the middle point are added as POIs (tagged different with mkgmap:line2poitype).
For lines each POI is tagged additionally with the following tags: mkgmap:line2poi=true mkgmap:line2poitype=start|end|inner|mid
Have fun! WanMil
Hi, would an 'add-pois-to-lines' option (similar to the new 'add-pois-to-areas') make sense ?
I tried to create an maxspeed layer to show the maxspeeds using the highway-shields, but this didn't work well (because garmin shows the shields only for some roads).
With the suggested add-pois-to-lines it would be possible to show little maxspeed icons (30) (50) etc. on the roads or to show incline-icons on roads which have an incline=* tag.
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Running the relation style earlier is a bit contrary to the mkgmap design but it seems to work (I don't know if processing of mp files is affected by this?). Anyhow the relation style is a bit different from the other style files as no garmin objects are created. So I think I can live with it. @Steve: What do you think? I think you have created big parts of the style system and so you should be happy with that change.
Seems to me that its fine to do the relations as early as possible, since they only modify other objects. ..Steve
Moin, WanMil schrieb am 31.10.2011 21:35:
I have modified the patch by the following things: 1. The relation style is now applied before the POIs are added
Today I had the idea of solving the problem the other way around: Add the artificially created POIs as members to the relation. But doing the relation processing as soon as possible is perhaps in general a good idea, since anything can be member of a relation. Gruss Torsten
Moin, WanMil schrieb am 31.10.2011 21:35:
I have also uploaded a compiled version of the patch: http://files.mkgmap.org.uk/detail/40
I tried this version: The handling of the relations is now working as expected and I have not noticed any adverse side effects. So I like it!!! Gruss Torsten
participants (8)
-
Chris66 -
Felix Hartmann -
Henning Scholland -
Marko Mäkelä -
Minko -
Steve Ratcliffe -
Torsten Leistikow -
WanMil