[mkgmap-dev] africa map 2
re downloaded the osm.bz file , it also failed due to bounds exception africa.pbf file . failed also , just 5 mb map file , when the input file is 731 mb pbf file osm.bz = 1.3 gb both have now failed Stephen ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Lake Geneva is dry - fixed
fixed a corrupt multipolygon section at Château de Glérolles (west of Saint-Saphorin). unfortunately the tile in question is too large for download by overpass api and the verification is not possible before 6th of january when europe-latest.osm.pfb at geofabrik is updated. Hanspeter ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Lake Geneva is dry: how to find the error?
Hi, one more hint. I tested the OpenMTBmap from Felix (Alps) from today. There the Lake Geneve is dry too - another part, but I assume that depends on the tiles. Regards, Gert Gesendet: Sonntag, 04. Januar 2015 um 22:07 Uhr Von: thesurve...@wolke7.net An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Lake Geneva is dry: how to find the error? Hi, today I tried to build a new version of a map which I created last November. It's a map of the area around Lake Geneva. I have the working environment from November available, so I thought I can reuse it. I created the map out of an europe extract from Geofabrik and I downloaded today the current extract and started the build. All the other things (the build script with parameters, sea-file, bounds-file) stayed the same as in November. All went fine until I had a look at the map - Lake Geneva is dry (see attached screenshot). The grey lines in the screenshot show the tiles of the map (from splitter). All other things like routing seem to work as aspected and all other lakes around are ok too (at least those which I have checked. I updated my environment to the actual versions but the result is the same. Now I use mkgmap: r3392 splitter: r416 precompiled sea: sea_20141027.zip precompiled bounds: bounds_20141027.zip pbf: europe-150103.osm.pbf from Geofabrik At this time I don't have an idea how to search for the error. It would be fine if someone of the list could give me an hint how to start with searching. What do you think: is it a data problem? splitter problem? mkgmap-problem? style-problem? what else? Regards, Gert ___ 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
Re: [mkgmap-dev] small issue with Way.getCofG()
Hi Gerd, yep, good catch. Seems to be a good solution for mkgmap! WanMil Hi WanMil, I think the problem is similar to finding the "largest circle in a concave polygon", and we are not interested in the exact solution, any point close enough to the center is good. See e.g. http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf which contains an iterative algo. Gerd WanMil wrote Hi Gerd, a good algorithm to find a point for the --add-pois-to-areas option would be to use the straight skeleton algorithm (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012394.html). This might be used to find a point with maximum distance to the border of a polygon. Anyhow it seems to be a complex algorithm so maybe not the ideal solution for mkgmap. WanMil Hi Steve, Steve Ratcliffe wrote On 03/01/15 08:15, Gerd Petermann wrote: @Steve: The routine was initially created for the --check-roundabouts option. Later it was also used for --add-pois-to-areas and the --housenumbers option. I got the impression that it might be better to calculate the center of the way bbox for those two, I am not so sure about the roundabout code. What do you think? Seems like the current method would tend to place the point near the most complex part of the boundary. This may not be bad, I would have to see lots of real examples to be sure. Yes, correct. I compared these three algos: 1) the existing 2) my patched one 3) center of bbox For complex shapes (many points), 1) and 2) produce almost equal results, and in fact the point was more often within the shape. For simple polygons like small parks, buildings, etc. 1) is worst, 2) is better and 3) is best. My conclusion: the patch is a simple and good improvement, for housenumber location calculation maybe it would be better to use algo 3). Steve Ratcliffe wrote Anyway there are no easy (or even any difficult!) methods that work in all cases, so I would just keep it as it is and perhaps should the calculated point be outside the box, move it to the closest point inside. I already looked at the link provided by Andrzej. If I got that right, we have two different problems regarding the generated POI: We calculate it once for the whole polygon, before clipping it to the bbox of the tile, and it might be outside of the polygon as well as outside of the bbox. This brought me back to the non-rectangular tile problem and I stop searching for a solution for the POI problem. Reg. non-rectangular tiles: I fear we can't use any of the existing algos in mkgmap to implement this, I'll report details in a different post. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828952.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828986.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ 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
Re: [mkgmap-dev] small issue with Way.getCofG()
Hi Gerd, > we are not interested in the exact solution See example from QGIS plugin, function centroids(self): https://github.com/zsiki/realcentroid/blob/master/realcentroid.py -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] small issue with Way.getCofG()
Hi WanMil, I think the problem is similar to finding the "largest circle in a concave polygon", and we are not interested in the exact solution, any point close enough to the center is good. See e.g. http://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf which contains an iterative algo. Gerd WanMil wrote > Hi Gerd, > > a good algorithm to find a point for the --add-pois-to-areas option > would be to use the straight skeleton algorithm > (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012394.html). This > might be used to find a point with maximum distance to the border of a > polygon. Anyhow it seems to be a complex algorithm so maybe not the > ideal solution for mkgmap. > > WanMil > >> Hi Steve, >> >> Steve Ratcliffe wrote >>> On 03/01/15 08:15, Gerd Petermann wrote: @Steve: The routine was initially created for the --check-roundabouts option. Later it was also used for --add-pois-to-areas and the --housenumbers option. I got the impression that it might be better to calculate the center of the way bbox for those two, I am not so sure about the roundabout code. What do you think? >>> >>> Seems like the current method would tend to place the point near the >>> most complex part of the boundary. This may not be bad, I would have >>> to see lots of real examples to be sure. >> >> Yes, correct. I compared these three algos: >> 1) the existing >> 2) my patched one >> 3) center of bbox >> For complex shapes (many points), 1) and 2) produce almost equal >> results, and in fact the point was more often within the shape. >> For simple polygons like small parks, buildings, etc. 1) is worst, >> 2) is better and 3) is best. >> >> My conclusion: the patch is a simple and good improvement, >> for housenumber location calculation maybe it would be better to use >> algo 3). >> >> >> Steve Ratcliffe wrote >>> Anyway there are no easy (or even any difficult!) methods that work in >>> all cases, so I would just keep it as it is and perhaps should the >>> calculated point be outside the box, move it to the closest point >>> inside. >> >> I already looked at the link provided by Andrzej. >> If I got that right, we have two different problems regarding >> the generated POI: >> We calculate it once for the whole polygon, before clipping >> it to the bbox of the tile, and it might be outside of the polygon >> as well as outside of the bbox. >> >> This brought me back to the non-rectangular tile problem and I stop >> searching for a solution for the POI problem. >> >> Reg. non-rectangular tiles: I fear we can't use any of the existing >> algos in mkgmap to implement this, I'll report details in a different >> post. >> >> Gerd >> >> >> >> >> -- >> View this message in context: >> http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828952.html >> Sent from the Mkgmap Development mailing list archive at Nabble.com. >> ___ >> mkgmap-dev mailing list >> > mkgmap-dev@.org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > ___ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828986.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] small issue with Way.getCofG()
Hi Gerd, a good algorithm to find a point for the --add-pois-to-areas option would be to use the straight skeleton algorithm (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012394.html). This might be used to find a point with maximum distance to the border of a polygon. Anyhow it seems to be a complex algorithm so maybe not the ideal solution for mkgmap. WanMil Hi Steve, Steve Ratcliffe wrote On 03/01/15 08:15, Gerd Petermann wrote: @Steve: The routine was initially created for the --check-roundabouts option. Later it was also used for --add-pois-to-areas and the --housenumbers option. I got the impression that it might be better to calculate the center of the way bbox for those two, I am not so sure about the roundabout code. What do you think? Seems like the current method would tend to place the point near the most complex part of the boundary. This may not be bad, I would have to see lots of real examples to be sure. Yes, correct. I compared these three algos: 1) the existing 2) my patched one 3) center of bbox For complex shapes (many points), 1) and 2) produce almost equal results, and in fact the point was more often within the shape. For simple polygons like small parks, buildings, etc. 1) is worst, 2) is better and 3) is best. My conclusion: the patch is a simple and good improvement, for housenumber location calculation maybe it would be better to use algo 3). Steve Ratcliffe wrote Anyway there are no easy (or even any difficult!) methods that work in all cases, so I would just keep it as it is and perhaps should the calculated point be outside the box, move it to the closest point inside. I already looked at the link provided by Andrzej. If I got that right, we have two different problems regarding the generated POI: We calculate it once for the whole polygon, before clipping it to the bbox of the tile, and it might be outside of the polygon as well as outside of the bbox. This brought me back to the non-rectangular tile problem and I stop searching for a solution for the POI problem. Reg. non-rectangular tiles: I fear we can't use any of the existing algos in mkgmap to implement this, I'll report details in a different post. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828952.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ 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
Re: [mkgmap-dev] small issue with Way.getCofG()
Hi Steve, Steve Ratcliffe wrote > On 03/01/15 08:15, Gerd Petermann wrote: >> @Steve: >> The routine was initially created for the --check-roundabouts option. >> >> Later it was also used for --add-pois-to-areas and the --housenumbers >> option. >> I got the impression that it might be better to calculate the center >> of the way bbox for those two, I am not so sure about the roundabout >> code. >> What do you think? > > Seems like the current method would tend to place the point near the > most complex part of the boundary. This may not be bad, I would have > to see lots of real examples to be sure. Yes, correct. I compared these three algos: 1) the existing 2) my patched one 3) center of bbox For complex shapes (many points), 1) and 2) produce almost equal results, and in fact the point was more often within the shape. For simple polygons like small parks, buildings, etc. 1) is worst, 2) is better and 3) is best. My conclusion: the patch is a simple and good improvement, for housenumber location calculation maybe it would be better to use algo 3). Steve Ratcliffe wrote > Anyway there are no easy (or even any difficult!) methods that work in > all cases, so I would just keep it as it is and perhaps should the > calculated point be outside the box, move it to the closest point > inside. I already looked at the link provided by Andrzej. If I got that right, we have two different problems regarding the generated POI: We calculate it once for the whole polygon, before clipping it to the bbox of the tile, and it might be outside of the polygon as well as outside of the bbox. This brought me back to the non-rectangular tile problem and I stop searching for a solution for the POI problem. Reg. non-rectangular tiles: I fear we can't use any of the existing algos in mkgmap to implement this, I'll report details in a different post. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/small-issue-with-Way-getCofG-tp5828821p5828952.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to display U. S. highway shields with numbers only
Hi Mark,
mkgmap uses the String.replaceAll() method
when subst is used with a regular expression.
Here is the link to the Oracle docu which also
contains a link to regular expressions.
http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#replaceAll%28java.lang.String,%20java.lang.String%29
regex:
http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#sum
Gerd
Mark Bradley-2 wrote
> Gerd,
>
>
>
> Thanks for the followup. Somehow I overlooked the Substitution filter
> that
> you suggest, which seems like a good idea. It looks like your idea also
> involves an Oracle Regex expression, with which I am not familiar. I
> thought about that, but the URL in the Conversion Style Manual for the
> Regex
> documentation is no longer correct. (Can someone on this mailing list see
> that it is corrected?) After a little searching on the Java website, I
> did
> not find the documentation, and did not want to take a lot of time
> looking,
> so I tried a different tack. After much thought, I came up with a series
> of
> commands that seems to produce the desired output. However, it looks like
> the idea of using the Substitution filter might produce a more elegant
> solution. I will probably look into that.
>
>
>
> Anyway, here is the sequence of commands I came up with that seemed to
> work.
> (I live in Indiana.) I have only included the commands that pertain to U.
> S. and state highways. The motorways (interstates) were more
> straightforward and a lot easier, because their ref values are much more
> consistent. The problem I had to overcome with the other highways is that
> the number of characters in the ref key value can vary, from none, to one
> or
> more.
>
>
>
> # Append extra characters to the end of the ref value to ensure it is more
> than one character in length, otherwise an error will be returned by the
> Substring filter later.
>
> # ("AB" are dummy characters.)
>
> highway = * & ref = * { set ref = '$(ref) AB' }
>
>
>
> # Create the letter_ref key that will determine later what type of symbol
> to
> display on the highway.
>
> highway = * & ref = * { set letter_ref = '$(ref|substring:0:2)' }
>
>
>
> # Extract the numbers only from the ref value, which will become the
> numbers
> inside the symbols.
>
> highway = * & ref = * { set number_ref = '$(ref|part:" :-2)' }
>
>
>
> #If the highway is a U. S. highway, use a shield symbol.
>
> letter_ref = 'US' {name '${number_ref|highway-symbol:shield:3} ${name}' |
> '${number_ref|highway-symbol:shield:3}' | '${name}'; addlabel '${name}
> (${ref})' }
>
>
>
> # If the highway is a state highway, use a round symbol.
>
> letter_ref = 'SR' | letter_ref = 'IN' {name
> '${number_ref|highway-symbol:round:3} ${name}' |
> '${number_ref|highway-symbol:round:3}' | '${name}'; addlabel '${name}
> (${ref})' }
>
>
>
> _
>
>
>
> Hi Mark,
>
>
>
> okay, so your problem is not directly related to the highway symbols.
>
> What you need is a simple filter to return the part of a string which
> starts
> at the first digit. I guess this can be done with subst plus a regular
> expression, but I'm not sure how exactly.
>
> Something like
>
> ref=* {set my_ref = ${ref|subst:"[a-zA-Z]*~>"}
>
>
>
>
>
> Gerd
>
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
View this message in context:
http://gis.19327.n5.nabble.com/How-to-display-U-S-highway-shields-with-numbers-only-tp5828938p5828949.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to display U. S. highway shields with numbers only
-- View this message in context: http://gis.19327.n5.nabble.com/How-to-display-U-S-highway-shields-with-numbers-only-tp5828938p5828947.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] africa map try 2
Hi Steve, I've downloaded africa-latest.osm.pbf from geofabrik yesterday and splitter had no problem with it. Please provide more details, e.g. your script. Gerd steve sgalowski wrote > re downloaded the map again > put it into my osm-data directory > run the script > > same thing again , looks like the file on the server may be corrupted or > broken > > stephen > > ___ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/africa-map-try-2-tp5828934p5828946.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] small issue with Way.getCofG()
On 03/01/15 08:15, Gerd Petermann wrote: @Steve: The routine was initially created for the --check-roundabouts option. Later it was also used for --add-pois-to-areas and the --housenumbers option. I got the impression that it might be better to calculate the center of the way bbox for those two, I am not so sure about the roundabout code. What do you think? Seems like the current method would tend to place the point near the most complex part of the boundary. This may not be bad, I would have to see lots of real examples to be sure. Anyway there are no easy (or even any difficult!) methods that work in all cases, so I would just keep it as it is and perhaps should the calculated point be outside the box, move it to the closest point inside. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
