Re: [mkgmap-dev] What is ${mkgmap:boundary_name}
On Sat, Dec 04, 2010 at 12:48:10PM +0700, garvanmaew wrote:
I first tried using the option --name-tag-list=name:en, name
I have never tried that option, so I don't know if it affects relations.
I guess I could easily test it by checking Finnish/Russian boundary on
my map.
For what it is worth, I would not use the option in 'production',
because some areas in Finland use Swedish name (and may have name:fi)
while most areas use Finnish name (and may have name:sv). I would want
to keep the name, except maybe when it is neither Swedish nor Finnish
(e.g., the Russian names that even require a character set conversion).
I do not know how to express this in --name-tag-list. And even then, I
could get problems with foreign-language objects, such as embassies and
historic things like name='Deutscher Soldatenfriedhof' (name==name:de,
not name:fi or name:sv).
I guess that we could benefit from a 'black list' of languages. If
transliteration is needed for name, try to use another name:*, e.g.,
--replacement-name-list=name:en,name:fi,name:sv.
expecting that the boundaries would now use the name:en tag, but this
had no effect that I could see. Next I tried editing the line style,
and I got the tags to display in English by commenting out this line:
boundary=administrative { name '${mkgmap:boundary_name}' }
This appears to be setting the name of administrative boundaries to
mkgmap:boundary_name, so I was wondering where mkgmap:boundary_name
gets its value?
As Charlie Ferrero suggested, it should get the value from the name of
the boundary relation. The question is if relations ignore the
name-tag-list option.
# Names of administrative boundaries.
# We could want to sort the relations in ascending order of admin_level
# and alphabetically by name first.
# Currently, the matching relations will be processed and the names
# appended to the boundary lines in an arbitrary order.
(type=boundary | type=multipolygon) boundary=administrative name=*
{ apply
{
set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' |
'${name}';
}
}
As a workaround for the possible --name-tag-list bug, you could try
replacing ${name} in the above rule with ${name:en}. If it does not
help, check that relations actually carry a name:en.
Ideas for tweaking the style language so that the resulting name list
will be sorted are welcome.
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Bug: relation names do not obey name-tag-list
On Sat, Dec 04, 2010 at 12:37:59PM +0200, Marko Mäkelä wrote:
The question is if relations ignore the name-tag-list option.
This seems to be the case. I just added the following to my mkgmap.args:
name-tag-list: name:fi,name:sv,name:en,name
It did something, because I saw many Swedish names in Helsinki and
Espoo, instead of the usual Finnish. They are (in my opinion incorrectly)
tagged as name=Finnish_name, name:sv=Swedish_name, missing name:fi.
However, the name of the Finnish-Russian border line segment that I
checked still contained the Russian ${name}s Leningradskaja Oblast and
Rossiskaja Federacia, even though the relations in question do carry
${name:fi}, which should have been selected instead of the ${name}:
http://www.openstreetmap.org/browse/relation/176095
http://www.openstreetmap.org/browse/relation/60189
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] rendering roundabouts
Roundabouts with nodes 8m from each other are rendered fine. But if the nodes are closer to each other mkgmap doesn't seem to translate them very well to the lower resulution of the Garmin grid. This not only happens to roads but other elements as well, even straight lines are converted into jagged structures (if the nodes are very close). See for instance the buildings and lakes on this map (my Openfietsmap): http://picasaweb.google.com/101124410619265439590/Openfietsmap#5546803050381040146 Here a screenshot of Merkaartor: http://picasaweb.google.com/101124410619265439590/Openfietsmap#5546803053933176658 Here is the link to the osm map: http://www.openstreetmap.org/?lat=52.189706lon=5.400034zoom=18layers=M The mkgmap settings that I use are shown here: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.args WanMil wrote: Once again: Garmin coordinates have a much lower resolution than OSM coordinates. The roundabout is quite small (~25m), so I do not wonder if this roundabout will not be as round as you might expect. Do you know another roundabout with the same dimension that is rendered as you expect? WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] What is ${mkgmap:boundary_name}
On Sat, 2010-12-04 at 12:37 +0200, Marko Mäkelä wrote:
snip
As Charlie Ferrero suggested, it should get the value from the name of
the boundary relation. The question is if relations ignore the
name-tag-list option.
# Names of administrative boundaries.
# We could want to sort the relations in ascending order of admin_level
# and alphabetically by name first.
# Currently, the matching relations will be processed and the names
# appended to the boundary lines in an arbitrary order.
(type=boundary | type=multipolygon) boundary=administrative name=*
{ apply
{
set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' |
'${name}';
}
}
As a workaround for the possible --name-tag-list bug, you could try
replacing ${name} in the above rule with ${name:en}. If it does not
help, check that relations actually carry a name:en.
Ideas for tweaking the style language so that the resulting name list
will be sorted are welcome.
Best regards,
Marko
The relations are tagged consistently in my case (better than the tag in
the ways), so your idea of using ${name:en} in the relations rule works
perfectly.
Thanks for your help. And it does look like there is a bug in handling
the --name-tag-list.
Apologies to those who group messages by thread in their email program,
I just realized that I inserted my first post into an existing thread by
mistake.
Garvan
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Amenity=shelter
Hi, This becomes Campground/RVPark with the default style. Surely, this is not intended? Cheers, Peter. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Building the planet splitter from the crosby_integration branch
Just a quick note. This is the code for splitting the planet into thousands of areas in a single pass based on the mkgmap splitter. I mentioned this code on both osm-dev and mkgmap-dev. This branch supports PBF, runs much faster, threads better, doesn't have the 'node in too many areas' issue, and split thousands of areas in one pass. ( See http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg06934.html ) This code has several external dependencies that I should have cataloged before, but didn't. You need the dsiutils and fastutils jar's available at: http://dsiutils.dsi.unimi.it/ http://fastutil.dsi.unimi.it/ You also need to use protobuf 2.3, available at: http://code.google.com/p/protobuf/ The sources for the osmbin jar needed to parse PBF files can be found at: https://github.com/scrosby/OSM-binary or the jar can be extracted from the sources for osmosis. This repository also contains the *.proto definitions if anyone is curious. I build and run with eclipse and openjdk with: java version 1.6.0_18 Scott ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Amenity=shelter
On Sun, Dec 05, 2010 at 04:03:44PM +1300, Peter Hendricks wrote: This becomes Campground/RVPark with the default style. Surely, this is not intended? In the wiki, there is no tourism=shelter. So, amenity=shelter has been used to tag some of these: http://en.wikipedia.org/wiki/Lean-to#Laavu What kind of a shelter do you have in mind? If it is a bus stop shelter, then it should be highway=bus_stop, shelter=yes. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
