Re: [mkgmap-dev] Analysis of MP issues in Finland
> It would be great if we could print a message saying "outer polygon does > not contain one or more inner polygons; should some outer and inner roles > be swapped?" Yep, I just have to think about how to code that. The idea to check if an outer polygon does not contain any inner polygon is a good starting point (sounds very simple but simple is good :-). Additionally I could check if the outer polygon is contained by an inner polygon that is not contained by an outer polgon. So we can swap the rule and say: Check all inner polygons that are not contained by an outer polygon and complain about that. Sounds good and too difficult to implement :-) > > By the way, should we complain if there appear to be multiple outer polygons? > I know that the outer polygon can consist of multiple role=outer lines > (such as long coastlines split to 500 nodes each), but can there legitimately > be multiple outer polygons? Hmm yes, thinking about administrative borders, > such as Russia+Kaliningrad (Königsberg), Denmark+Greenland, or from the past > West Germany + West Berlin. It is defined in the description of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) that multiple outer polygons are allowed. And from my point of view it doesn't harm anything. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Analysis of MP issues in Finland
Hi WanMil, > This mp was changed today (Jan 29th 2010, 06:33). Before the change a > small polygon in the north of the mp touched the outer ring. So it > contains to your first category overlapping lines. Thanks for figuring this out. I was too lazy to check previous versions, and the Geofabrik extract is too big for my visualization tools. By the way, I examined one multipolygon near the border more closely. In the split osm.gz file, it contained fewer members than the relation at the browse URL, and it had not been changed recently. I wondered if it is a splitter bug, but the huge finland.osm.bz2 contained the same error. So, Geofabrik's tool of choice (Osmosis?) is apparently dropping the members that are outside its cutting area. > > 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: > > Multipolygon http://www.openstreetmap.org/browse/relation/375636 contains > > intersected or overlapping ways > The inner and outer tags are interchanged. Mp could autodetect this but > only if it disregards the inner and outer tags completely. This makes > problems with your next examples, because the wrong assigned inner > polygons would be autodetected as outer polygons. Thank you, I should have loaded it in JOSM to see it. I just swapped the roles. > > Last but not least, here is an idea for quality control. > > I came across two lakes whose islands were in another lake > > (the change message hinted that the lake had been split). > > There is no warning for that. The errors must be coming > > from missing boundary information in the Geofabrik extract. > > > > http://www.openstreetmap.org/browse/relation/303320 > > http://www.openstreetmap.org/browse/relation/303321 > > Yep. At the moment the mp code is quite unspecific with its warning > messages. "Multipolygon http://www.openstreetmap.org/browse/relation/xxx > contains intersected or overlapping ways" is the only message if > something is not correctly inner/outer tagged, or some ways are > overlapping or inner ways belong to a complete other mp. I will think > about how to improve this. It would be great if we could print a message saying "outer polygon does not contain one or more inner polygons; should some outer and inner roles be swapped?" By the way, should we complain if there appear to be multiple outer polygons? I know that the outer polygon can consist of multiple role=outer lines (such as long coastlines split to 500 nodes each), but can there legitimately be multiple outer polygons? Hmm yes, thinking about administrative borders, such as Russia+Kaliningrad (Königsberg), Denmark+Greenland, or from the past West Germany + West Berlin. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Analysis of MP issues in Finland
Hi Marko, > Hi WanMil, Mark, all, > > I analyzed all the multipolygon errors and warnings I got for today's > finland.osm.bz2 from Geofabrik, without --generate-sea. that's great!! > > Most of them can apparently be blamed on missing boundary information. > I wrote the relation IDs an explanations to my logging.ignore file, so > that I will not have to see these messages again. You can get the file > from http://www.polkupyoraily.net/osm/, > but I will repeat the interesting bits here: > > # overlapping lines in multipolygons, should be fixed in mkgmap later > http://www.openstreetmap.org/browse/relation/48542 > http://www.openstreetmap.org/browse/relation/367049 > http://www.openstreetmap.org/browse/relation/372975 > http://www.openstreetmap.org/browse/relation/387793 > http://www.openstreetmap.org/browse/relation/389976 > # multipolygon problem at tile border, should be fixed in mkgmap or splitter > http://www.openstreetmap.org/browse/relation/302897 > http://www.openstreetmap.org/browse/relation/306274 > http://www.openstreetmap.org/browse/relation/311221 Ok, the number is quite small. Finnland contains ~2300 multipolygons. So the result is not too bad :-) > > (the offending tile border is at lat=62.226562; > the other one is at lat=64.819336) > > I could not see what is causing the following issues. > WanMil, can you please analyze these? One of them was edited recently, > but the other was not, as far as I can tell: > > 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: > Multipolygon http://www.openstreetmap.org/browse/relation/372970 contains > intersected or overlapping ways This mp was changed today (Jan 29th 2010, 06:33). Before the change a small polygon in the north of the mp touched the outer ring. So it contains to your first category overlapping lines. > 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: > Multipolygon http://www.openstreetmap.org/browse/relation/375636 contains > intersected or overlapping ways The inner and outer tags are interchanged. Mp could autodetect this but only if it disregards the inner and outer tags completely. This makes problems with your next examples, because the wrong assigned inner polygons would be autodetected as outer polygons. > > Last but not least, here is an idea for quality control. > I came across two lakes whose islands were in another lake > (the change message hinted that the lake had been split). > There is no warning for that. The errors must be coming > from missing boundary information in the Geofabrik extract. > > http://www.openstreetmap.org/browse/relation/303320 > http://www.openstreetmap.org/browse/relation/303321 Yep. At the moment the mp code is quite unspecific with its warning messages. "Multipolygon http://www.openstreetmap.org/browse/relation/xxx contains intersected or overlapping ways" is the only message if something is not correctly inner/outer tagged, or some ways are overlapping or inner ways belong to a complete other mp. I will think about how to improve this. > > Best regards, > > Marko Well done! WanMil P.S.: I will start to analyze the mp seabounds treatment and will post it soon. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1538: Print expected result rather than repeating the actual result.
Version 1538 was commited by steve on 2010-01-29 18:14:52 + (Fri, 29 Jan 2010) BRANCH: style Print expected result rather than repeating the actual result. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
Am 29.01.2010 um 17:47 schrieb Christoph Wagner:
> Thilo Hannemann schrieb:
>> The reason why you need a matching polygon rule for POIs to be generated is
>> that mkgmap needs this to find out that it is a polygon.
>
> Now I really understand the problem. Would it be enough for mkgmap to specify
> a rule in polygons-file like this:
>
> building=*
>
> without any actions and typemappings, just to find out that building is a
> polygon tag and get a point out of it?
I don't know, but I think it won't work. mkgmap might complain about the
syntax, so you could try
building=* { set dummy=dosomething }
instead. But actions alone don't invoke the code for the polygon creation at
all IIRC, so that probably won't work either.
You could try to patch mkgmap so you can have a "dummy" type that won't trigger
the creation of the actual polygon. Maybe that's what happens if you specify a
type that can't be converted into any Garmin type (say 0x) anyway. So
it would be
building=* [ 0xff resolution 24 ]
or something like that. On the other hand - if the code checks the validity of
the Garmin type mkgmap will complain, if it doesn't check it the resulting map
will probably be broken.
Regards
Thilo
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
Thilo Hannemann schrieb: > The reason why you need a matching polygon rule for POIs to be generated is > that mkgmap needs this to find out that it is a polygon. > Now I really understand the problem. Would it be enough for mkgmap to specify a rule in polygons-file like this: building=* without any actions and typemappings, just to find out that building is a polygon tag and get a point out of it? signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duo Tagged polygon.
Steve Ratcliffe wrote: > Hello > This is not so easy, because you don't know if something is a line or > a polygon until you look it up. Having the first point equal to the > last is not decisive because sometimes lines go in circles (eg. > roundabouts, fence around a field) and sometimes polygons are split > into pieces. > > Sometimes whether something is to be a line or a polygon depends on > the map. So for instance county boundaries are often represented by a > multi-polygon in OSM but we represent boundaries by a line on the map. > If you were creating a political map though you might want to use > areas instead. > > Thats not to say there are no improvements possible (for instance the > multipolygon relation did not exist when the current scheme was > designed, but might be a hint that something should be a polygon - > although in the cases when it is used as a boundary this is not valid > for us), but keep in mind that the style is deciding the structure of > the map and not just how it looks. > Thanks for reply. I understand the problem now. Cheers Dave F. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duo Tagged polygon.
Mark Burton wrote: > No, the style files also decide which ways are routable and which are > not. Ok, I've learnt something new, thanks. However I'm still failing to understand why a linear way needs information from the polygon file. Isn't all the data it needs stored in the line file? Cheers Dave F. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duo Tagged polygon.
Hello > What I was suggesting is that when mkgmap finds a line it looks in the > line style& no other,& when it finds a polygon it looks in polygon& > no other. There would be no order or priority, mkgmap would look This is not so easy, because you don't know if something is a line or a polygon until you look it up. Having the first point equal to the last is not decisive because sometimes lines go in circles (eg. roundabouts, fence around a field) and sometimes polygons are split into pieces. Sometimes whether something is to be a line or a polygon depends on the map. So for instance county boundaries are often represented by a multi-polygon in OSM but we represent boundaries by a line on the map. If you were creating a political map though you might want to use areas instead. Thats not to say there are no improvements possible (for instance the multipolygon relation did not exist when the current scheme was designed, but might be a hint that something should be a polygon - although in the cases when it is used as a boundary this is not valid for us), but keep in mind that the style is deciding the structure of the map and not just how it looks. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duo Tagged polygon.
Hi Dave, > I don't see how that would affect routers. I thought these style files > just decided what colours were used to display on the screen. The data > in the IMG would still be the same wouldn't it? No, the style files also decide which ways are routable and which are not. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duo Tagged polygon.
Felix Hartmann wrote: > No because streets have higher priority, as routing is to most people > more important. > Well, that debatable, but anyway... What I was suggesting is that when mkgmap finds a line it looks in the line style & no other, & when it finds a polygon it looks in polygon & no other. There would be no order or priority, mkgmap would look directly in the correct place instead of going through all the files. I don't see how that would affect routers. I thought these style files just decided what colours were used to display on the screen. The data in the IMG would still be the same wouldn't it? Are polygons used in routing? Wouldn't you just go round in circles? :-) > You could add [continue ...] to barrier=wall, and then there would be a > polygon too I think. As mentioned previously 'continue' doesn't work file to file :-( > The style-file reading is certainly a point where > much could be done better - but probably also take a lot more resources. > > > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duo Tagged polygon.
On 29.01.2010 15:44, Dave F. wrote: > Hi > > My last question got missed (Polygon with barrier problem) but I would > like to know the answer so I'm posting it again. > > As discussed (polygon) landuse=farmyard& barrier=wall wont render > landuse if (line) barrier=wall is present. > > Is there any development in progress to solve this problem? > > "mkgmap processes the style files in a strict order..." > > As I said, I'm a newbie so I may not understand fully, but wouldn't it > be better if, when mkgmap reads the OSM file& it finds a > polygon (first point=last point) then it should look directly in the > polygon file? > To me it seems a illogical to have an order. > No because streets have higher priority, as routing is to most people more important. You could add [continue ...] to barrier=wall, and then there would be a polygon too I think. The style-file reading is certainly a point where much could be done better - but probably also take a lot more resources. > On a more general note, As this is the only forum for mkgmap, would it > be worth setting up general question one so that queries by newbies like > me don't get hidden in amongst the busy coders here? > > Cheers > Dave F. > > > > > > ___ > 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
[mkgmap-dev] Duo Tagged polygon.
Hi My last question got missed (Polygon with barrier problem) but I would like to know the answer so I'm posting it again. As discussed (polygon) landuse=farmyard & barrier=wall wont render landuse if (line) barrier=wall is present. Is there any development in progress to solve this problem? "mkgmap processes the style files in a strict order..." As I said, I'm a newbie so I may not understand fully, but wouldn't it be better if, when mkgmap reads the OSM file & it finds a polygon (first point=last point) then it should look directly in the polygon file? To me it seems a illogical to have an order. On a more general note, As this is the only forum for mkgmap, would it be worth setting up general question one so that queries by newbies like me don't get hidden in amongst the busy coders here? Cheers Dave F. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1537: Initial code for the SRT file.
Version 1537 was commited by steve on 2010-01-29 13:26:12 + (Fri, 29 Jan 2010) Initial code for the SRT file. Not used by anything else yet. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Unchecked conversions and calls
I am compiling mkgmap with Sun javac with -Xlint:unchecked by commenting out the compilerarg definition in build.xml, and I get some warnings for unchecked calls and type conversions. I do not know Java well enough to fix these (I learned it before the generics were introduced and have not written much Java lately). I guess that some qualifiers would have to be added. Could someone please look at these? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Analysis of MP issues in Finland
Hi WanMil, Mark, all, I analyzed all the multipolygon errors and warnings I got for today's finland.osm.bz2 from Geofabrik, without --generate-sea. Most of them can apparently be blamed on missing boundary information. I wrote the relation IDs an explanations to my logging.ignore file, so that I will not have to see these messages again. You can get the file from http://www.polkupyoraily.net/osm/, but I will repeat the interesting bits here: # overlapping lines in multipolygons, should be fixed in mkgmap later http://www.openstreetmap.org/browse/relation/48542 http://www.openstreetmap.org/browse/relation/367049 http://www.openstreetmap.org/browse/relation/372975 http://www.openstreetmap.org/browse/relation/387793 http://www.openstreetmap.org/browse/relation/389976 # multipolygon problem at tile border, should be fixed in mkgmap or splitter http://www.openstreetmap.org/browse/relation/302897 http://www.openstreetmap.org/browse/relation/306274 http://www.openstreetmap.org/browse/relation/311221 (the offending tile border is at lat=62.226562; the other one is at lat=64.819336) I could not see what is causing the following issues. WanMil, can you please analyze these? One of them was edited recently, but the other was not, as far as I can tell: 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/372970 contains intersected or overlapping ways 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/375636 contains intersected or overlapping ways Last but not least, here is an idea for quality control. I came across two lakes whose islands were in another lake (the change message hinted that the lake had been split). There is no warning for that. The errors must be coming from missing boundary information in the Geofabrik extract. http://www.openstreetmap.org/browse/relation/303320 http://www.openstreetmap.org/browse/relation/303321 Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
