Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
On 10/13/11 11:48, Henning Scholland wrote: Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. there was a discussion on irc (#osm) about this yesterday. komzpa uses entrance for his render to show them : http://latlon.org/~komzpa/screenshots/entrance1.png Komzpa entrance=yes ref= addr:flats= entrance=yes was also added yesterday to osmarender stylesheet by petchange. Henning -- Rich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Am 10.10.2011 20:37, schrieb svn commit: Reimplementation of the add-pois-to-area option The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file. Didn't follow all the postings. Main question: Existing styles have to be adjusted, right? Or is it downward compatible to existing styles? Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (Fixed by workround) Bizarre flooding in South Wales
On 2011-10-10 19:33, Bartosz Fabianowski wrote: Replying to myself, I think I see the problem now. You are specifying paths relative to the current working directory while mkgmap searches relative to its installation directory. Try specifying the coastline file and the boundary directors as absolute paths. No - the problem was that I'd forgotten the '=' in the command-line syntax. Correct: --coastlinefile=coastlines_europe-111004.osm.pbf What I'd entered: --coastlinefile coastlines_europe-111004.osm.pbf It might be a worthwhile improvement for mkgmap to notice dud syntax like that and either accept the form without the '=' sign, or to put up an error message. As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing. Steve P.S: I can now confirm that Bartosz's fix (specifying a separate coastline file) appears to have completely fixed my flooding issues. Thank you Bartosz. Hopefully my experiences will help the coastline/flooding/tiles people get more of a grip on what's causing this problem. As I said last time, if anyone wants my files for investigations, I'll keep them for a while - just ask me and I'll send them. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (Fixed by workround) Bizarre flooding in South Wales
As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing. That is rather silly behavior indeed :). P.S: I can now confirm that Bartosz's fix (specifying a separate coastline file) appears to have completely fixed my flooding issues. I am quite convinced my analysis of the problem is correct. I know what is going wrong. And the only way to fix it that I can see is to use coastlines based on a larger extract that the one you are processing into a map. Hence, European coastlines when generating a map for the EU are not really a hack or a workaround. They are the correct solution. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (Fixed by workround) Bizarre flooding in South Wales
On 2011-10-13 12:07, Bartosz Fabianowski wrote: As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing. That is rather silly behavior indeed :). Well, hopefully one of the gurus will drop in a fix sometime. If it got me, it'll certainly get someone else. No point in having the list continually jammed with people asking what's the matter! P.S: I can now confirm that Bartosz's fix (specifying a separate coastline file) appears to have completely fixed my flooding issues. I am quite convinced my analysis of the problem is correct. I know what is going wrong. And the only way to fix it that I can see is to use coastlines based on a larger extract that the one you are processing into a map. Hence, European coastlines when generating a map for the EU are not really a hack or a workaround. They are the correct solution. Hmm - well I agree with you Bartosz that your analysis is correct. And the workaround is a good one, but quite honestly, it ought to be possible to handle coastlines directly. As I see it, the coastline problem (and a possible similar issue over other monster polygons like country boundaries) are the same. I did post about this before, but possibly we handle polygons (and polygon splitting) in too naiive a fashion. I would argue that whenever a splitter works on a map, it must keep any polygons complete in the output file: but to reduce all the points outside the tile's region-of-interest to a simple set of lines that skirt the boundary of the tile but located infinitesimally outside the region-of-interest, (possibly marked up as invisible), but preserving the closed nature of the polygon. So for instance, with my map of Wales, the splitter that generated Wales from the planet file would notice that the UK's coastline runs off the eastern side of the tile at the southern border of Gwent near the Second Severn Crossing (a bridge over the Severn Estuary into England). The splitter would follow the coastline right around the UK, noticing that it re-enters the Wales tile at the River Dee near Chester in the North East. So the splitter would replace all that UK coastline with a single (invisible) line joining the Severn Estuary in the south-east with the River Dee Estuary in the north-east, running just outside the eastern side of the Wales tile. That way, of someone took the Wales tile, and split it again to isolate just (say) the south west corner of Wales, then the coastline follower could easily repeat the same trick, as the invisible line alone Wales's eastern border maintains the continuity. It would be the same issue with country boundaries, city boundaries and other such things that might get chopped by a splitter. Notice also that a stitcher would be able to use this information to join two adjacent tiles and correctly maintain the polygon continuity. Steve ** ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (Fixed by workround) Bizarre flooding in South Wales
Following the coastline to check whether it enters the current tile again will work in Great Britain but may fail in continental Europe. The Geofabrik Europe extract does not have a closed coastline after all. That would have to go all around Asia and back. So yes, following the coastline out of the tile somehow is a good idea. But no, it is not as simple as following it until it enters the tile again :(. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Am 13.10.2011 11:19, schrieb Chris66: Am 10.10.2011 20:37, schrieb svn commit: Reimplementation of the add-pois-to-area option The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file. Didn't follow all the postings. Main question: Existing styles have to be adjusted, right? Or is it downward compatible to existing styles? If you haven't made any hacks in your Style-File to show more POI's, there shouldn't be a problem. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (Fixed by workround) Bizarre flooding in South Wales
On 2011-10-13 14:07, Bartosz Fabianowski wrote: Following the coastline to check whether it enters the current tile again will work in Great Britain but may fail in continental Europe. The Geofabrik Europe extract does not have a closed coastline after all. That would have to go all around Asia and back. That's right! What, you mean it doesn't go round Asia?? :-( Notice that once you've done the miserable tour of Asia once, then it's OK to split the resulting Europe tile to get a tile for just Poland (say) because the coastline to the east of Europe's area (i.e. around Asia) would by now have simplified to just a couple of straight (invisible, out-of-bounds) lines. So yes, following the coastline out of the tile somehow is a good idea. But no, it is not as simple as following it until it enters the tile again :(. - Bartosz Hmm - I don't know about that. Maybe with the data the way it is now, but I argue that we've got the data wrong if so. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Am 13.10.2011 11:19, schrieb Chris66: Am 10.10.2011 20:37, schrieb svn commit: Reimplementation of the add-pois-to-area option The major advantages are: * Only one POI per multipolygon * Add POIs before style processing so it is not necessary to have a rule in the polygons file if only a POI is wanted For more details look into the help text in the options file. Didn't follow all the postings. Main question: Existing styles have to be adjusted, right? Or is it downward compatible to existing styles? If you haven't made any hacks in your Style-File to show more POI's, there shouldn't be a problem. Henning Possible hacks that need to be or can be changed now are: 1. In the old implementation there was the requirement to have a rule in the polygons file for polygons for which a POI should be added. Some people added rules with transparent polygons so that the POI is visible but the polygon is not. This is no longer necessary. A rule in the points file is enough if you want to display the POI but not the polygon. 2. For the same reason you might have to change you points style now because for polygons that are not defined in the polygons style a POI is added anyhow if there is a rule in the points style. So you might add a rule like: aeroway=terminal mkgmap:area2poi!=true [0x2f04 resolution 22] See also Minkos post for full details. Have fun! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
mkgmap:area2poi=true Does this mean, if I don't want to have any POI that result from the add-pois-to-area option I can use a rule like: /amenity=restaurant mkgmap:area2poi!=true/ and only POI for restaurants that have been points in the OSM data, will be set. while amenity=restaurant /mkgmap:area2poi=true /would match only POI that are generated via add-pois-to-area option/ / ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
mkgmap:area2poi=true Does this mean, if I don't want to have any POI that result from the add-pois-to-area option I can use a rule like: /amenity=restaurant mkgmap:area2poi!=true/ and only POI for restaurants that have been points in the OSM data, will be set. while amenity=restaurant /mkgmap:area2poi=true /would match only POI that are generated via add-pois-to-area option/ / That's correct. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
On 10/13/11 11:48, Henning Scholland wrote: Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. there was a discussion on irc (#osm) about this yesterday. komzpa uses entrance for his render to show them : http://latlon.org/~komzpa/screenshots/entrance1.png Komzpa entrance=yes ref= addr:flats= entrance=yes was also added yesterday to osmarender stylesheet by petchange. Henning That's easy to implement. @list: Any objections? Is it necessary to create an additional mkgmap option to define which tags should be used as label node? At the moment there is building=entrance and entrance=yes. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
Hi, just a question: In osm-wiki I found a proposal for entrance=* as a new tag for entrances. So maybe this should also be considered? Or did you do so already? Also it could be possible, that there is more than one entrance in a polygon. So there should be a ranking. At the moment the first node in the polygon tagged building=entrance is used. For the future I propose to use the following order: 1. entrance=main 2. entrance=yes 3. building=entrance If more than one point of the same tag exist the first one is used. I think the other entrance tags should not be used. Ok? WanMil Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (Fixed by workround) Bizarre flooding in South Wales
Notice that once you've done the miserable tour of Asia once, then it's OK to split the resulting Europe tile Correct. So your idea would work but only if the extracts you begin with have coastlines generated in the same way, by following the parts that extend outside the tile boundaries. Right now, the extracts you get from Geofabrik have coastlines ending abruptly at their boundaries. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r2049: Reimplementation of the add-pois-to-area option
If more than one point of the same tag exist the first one is used. What if there are multiple entrances with different house numbers? This is common in many countries with those huge communist blocks of flats. - Bartosz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
