[mkgmap-dev] {Spam?} multipolygon with outer polygon within inner polygons
Hi, I'm trying to build a map of The Netherlands and got some problems with rendering the administrative borders correctly. Some parts were related to broken relations between tiles, but the major one was caused by a complex relation of enclaves/exclaves of Baarle in the south of the country. I examined this area more closely and narrowed the problem down to this situation, where I cant render the map correctly with mkgmap: A = one big outer ring (the Dutch municipality of Baarle-Nassau), B1, B2 = some islands inside (Belgium territory, role=inner) C= Within some of those islands there are polygons (Dutch, role=outer) It goes wrong with those outer polygons within the inner polygons. Simplification looks like this, where the two vertical border lines are not supposed to be there: http://img63.imageshack.us/img63/1002/bordersnl5.jpg The relation can be found at http://betaplace.emaitie.de/webapps.rel onId=47798 There are no gaps or faults within the relation as far as I can see. I put this question and a few examples of my map also on the forum at http://forum.openstreetmap.org/viewtopic.php?pid=59370 Thanks, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Those borderlines form part of different type of administration regions, (countries, provinces, municipalities etc). My question is not to understand why they are tagged like that, but how to make them render them well into mapsource. Is there some kind of patch I can try out, and where/how can I apply it? Im new regarding patching mkgmap, just using the latest release. Chris wrote: Hi, what I don't understand: Why is the complex MP processing for borders necessary while we are (mostly) only interested in the border _lines_ ? Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon with outer polygon within inner polygons
Thanks Steve, So, as I understand it, I need to change the default relation style file in order to convert those multipolygons into lines? When I look at other osm maps from the same area (openmtbmap, radfahrers map, computerteddy) I dont see those connecting lines between the borderlines. Looking at their style files I don't see a difference in how they handle the borders compared to the default style. So... how do they do this, if they use exactly the same osm data? If anybody who want to test it out, I put the osm data here: http://moh.freehostia.com/osm/nassau.osm (200kb, I only downloaded the border polygons of the municipality of Baarle-Nassau). Or an even more simple example can be found at http://moh.freehostia.com/osm/simple.osm (3kb) The last one is not real osm data, but a simplification of the situation. Steve Ratcliffe wrote: Thanks for that image as it shows the problem clearly. If the boundaries were being drawn as areas, then the lines would not be seen (or not much anyway) since they would be zero width. However since the borders are drawn as lines you clearly see the connecting lines. I think that the best way to solve this is for mkgmap to convert to multipolygon into separate lines in the case of boundaries. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] administrative borders (was: multipolygon with outer polygon within inner polygons)
Hi all,
It looks like I managed a way to render those complex multipolygon
administrative borders correctly now.
In the relation style file, I changed administrative borders statements like
this:
# country borders
(type=boundary | type=multipolygon) boundary=administrative admin_level=2
{ apply
{
set boundary2=yes;
set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}';
}
}
For my map of the Netherlands, I'm only interested in admin levels 2,4 and 8
(country/province/municipality) so I copied those lines for provinces
(set boundary4=yes for the lines and boundary4_name for the names) and
municipalities
(set boundary8=yes and boundary8_name) too.
I'm not sure if mkgmap: has any function, maybe
without this it will function as well?
In the line style file, I removed all the statements regarding to the admin.
borders
and replaced it with these lines:
boundary2=yes { name '${mkgmap:boundary2_name}' } [0x1e resolution 16]
boundary4=yes { name '${mkgmap:boundary4_name}' } [0x1d resolution 18]
boundary8=yes { name '${mkgmap:boundary8_name}' } [0x1c resolution 20]
I tested it with the complicated area, and it seems rendering fine now :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] administrative borders (was: multipolygon with outer polygon within inner polygons)
Yes, now you metion it, I notice that too.
If I change the ( . ) for { . } which seems more logical, it will give
not the display at the borders that I want.
At the National Border between Netherlands and Belgium for instance, now only
Belgium is displayed instead of the desired two names.
So I better leave it like in the default style.
Clinton Gladstone wrote:
Sun, 14 Feb 2010 04:50:22 -0800
On Feb 14, 2010, at 11:32, Minko wrote:
set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}';
Just out of interest, should the parentheses surrounding mkgmap:boundary2_name
not be curly brackets ('{', '}')? I noticed this in the default style as well.
Or is this a syntax which I am unfamiliar with?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Help from the style file gurus
Hi, I don't know if this already has been discussed, but some combinations of TYP file and overlays wont work in Mapsource. I'm trying to put oneway, bridge and tunnel symbols on the roads by using the layer style file. This works fine with tunnels and bridges, but with oneway symbols I noticed the following issue: For oneway streets I create in the TYP file a line element. Its a 3 pix bitmap with a a black arrow sign - in the centre line. I use the line symbol 0x00 (Road) to display this line, but any line that garmin can display, works. In the line overlay style file, I combine this arrow sign with the highways: 0x0200: 0x02, 0x00 (representing highway=primary oneway=yes or 1) 0x0300: 0x03, 0x00 (secondary roads / oneway) 0x0400: 0x04, 0x00 (tertiary / oneway) 0x0500: 0x05, 0x00 (unclassified / oneway) I noticed that: 1) Only on the LOWER class roads (0x04, 0x05 etc) the arrow display (that i put in the center of the bitmap) is displayed fine, as long as I draw the lines as BITMAP in the TYP file. It doesn't matter if they are either 1 or 2 colored bitmaps. So a yellow tertiary road, with black borderlines, and a black arrow in the centre of the road indicating the driving direction, will display fine. 2) If I draw the roads as line elements instead of bitmaps, the arrow is NOT displayed. 3) With MAJOR road types 0x02 and 0x03 however, the arrow only shows up if: - the roads are drawn as bitmap AND - the center of this bitmap (where the arrow is displayed) is transparent, otherwise it will be covered by the bitmap color of the road. With a line that is defined by two colored bitmaps, the arrow is covered and don't show on mapsource 4) As I said tunnels and bridges showed up fine, as long as the bitmap of these tunnels and bridges were wider then the bitmap of the roads. Of course this could be arrow signs or other symbols too, as long they are drawn outside of the road. I use mapsource 6.15.7, and I don't know if this behavior is a bug in mkgmap or is it a mapsource issue? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1576: There seems to be a way to show elevation profiles
Hi Mapsource (6.15.7) crashes when I click to see the profiles of the route: invalid map/setT iterator I have the elevation contour img's in one mapset with the osm map img tiles, combined them with mkgmap r1580 (with --show-profiles=1). If I make one mapset with only contour lines, I see an emtpy profile. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1576: There seems to be a way to show elevation profiles
Hi, I use the standard Garmin types for contour lines, 0x20, 0x21 and 0x22 I created the contour lines with Srtm2Osm, split srtm.osm data with the same tile area bounds as my map. Now I have two img's of the same area, one with osm data, one with contour lines. E.g. 10010001.img and 10010101.img The contour tile is transparent so I can see the contours on top of the map in Mapsource. Is it possible to merge those two layers into one tile and still keep the routing? How can I merge the two 10010001.osm with 10010101.osm or 10010001.img with 10010101.img? Will it be possible to show the elevation profile with this approach? Cheers, Minko Ronny Klier wrote: This will not work. I got the same problem in different versions of MapSource. May be there should be an explicit warning in show-profiles option help. If I make one mapset with only contour lines, I see an emtpy profile. This works fine for me (in 6.15.11). Did you use the standard Garmin types for elevation(0x20-0x21)? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1576: There seems to be a way to show elevation profiles
With some detours, I finally got the elevation profile working in my mapset ;-) I dont know if it now worked because I also installed Garmin Basecamp. First, I had all map tiles and contour img's in one mapset. They are still there, but now I created another tdb index file with mkgmap on all contour img's from the same mapset, with the options: --overview-mapname: contours_nl --show-profiles=1 --tdbfile I stored the contours_nl.tdb file and contours_nl.img overview map in the same directory, and installed it in Mapsource. The result is that I see the contours on top of the map (with routing), and I can choose to switch to the bare contour mapset without all osm data. In this mapset I can see now the elevation profile :-) On the GPS (tested a Etrex and Dakota) I can now switch the contours on and off, but routing doesn't show the elevation profile. You can download and view some images of my custom maps on my website: http://sites.google.com/site/openfietsmap ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Hi,
I have problems rendering this kind of relation:
http://www.openstreetmap.org/browse/relation/1525
Many lakes in the Netherlands are automatically tagged (AND import) like this.
The lake is a multipolygon, where the outer border is tagged as natural=water
(role=outer)
and the inner border (for instance an island in this lake) as natural=water
(role=inner) too.
When I render this, the islands in those lakes are flooded.
Of course it would be better not to tag those inner borders at all, or use
landuse=* or natural=land
Is there a method in the style file to flag ways with role=outer and role=inner
from
the same multipolygon?
What I would like to do is something like this:
From lake A with type=multipolygon and way A1 {natural=water role=outer} and
way A2 {natural=water role=inner}
remove the tag natural=water from way A2 (or retag natural=water to
natural=land?)
Is this possible?
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Thanks Marko,
The tag natural=water is not assigned to the relation (only type=multipolygon)
so this is not working.
Is it possible to write a condition for role=outer natural=water
{ apply role=inner { set natural=land
} } ??
Here another example of that kind of relation:
http://maps.google.de/maps?f=qhl=degeocode=q=http://betaplace.emaitie.de/webapps.relation-analyzer/downloadServlet/kml/1525ie=UTF8
The red way (island) is flooded in my map (and other osm maps as well).
What I noticed is that on other maps (radfahrer, openmtb) which were made with
previous versions of mkgmap
those islands were not flooded, but now they are. So it was somehow possible,
but how?
Regards,
Minko
Marko Mäkelä wrote:
Something like this (not tested) in the relations file of your style
should do the trick:
type=multipolygon natural=water { apply role=inner { set natural=land
} }
This will assign natural=land to each inner member of multipolygon
relations.
As far as I understand, it is not possible to write other conditions
for the apply than role. And you cannot match role by regular
expression. In this case, you cannot add a condition that you only want
to set natural=land for those inner members that had natural=water.
I do not know when the custom multipolygon processing kicks in. It
could be that the style rules are executed after that, and it is too
late to adjust anything with style rules.
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] multipolygons: how to flag role=inner role=outer in Style file?
Felix, natural=water role=inner in the polygons style file (if a rule like that would be possible at all?) will not be a solution, because then also lakes within (multipolygon) forests are tagged like this too and will be affected. For my case it only has to be applied on relations where both role=inner and role=outer are tagged with natural=water The last version of openmtbmap that worked correct for this relation was in december 2009 I guess. Radfahrers map of Europa from 09-01-2010 seems also working ok for this kind of relation. But maybe in my case its better to accept that the Dutch way of osm tagging is wrong and has to be altered instead of finding a way to solve this with mkgmap ;-) Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Hi,
I've tried to put in the relation file:
type=multipolygon { apply role=inner { set inner=yes } }
And in the polygons file:
natural=water inner=yes [0x27 resolution 14]
But it seems not doing anything.
Looks like the multipolygon processing is done before it reads the
relation style file?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bug in road-name-pois
Hi, The option --road-name-pois often creates place names that are totally wrong. Two adjacent streets in the same district can have different place names. I think it is better not to show the place name until this problem is solved? Is there a way to make these POI invisible on the map? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] how to differentiate road types with zoom levels?
Hi, I was wondering if it is possible to use two different layouts for the same road on different zoom levels. For instance a small 1pix line on lower zoom levels, and a wider 3pix line with dark borders on the highest level. In the TYP file I use 0x00 road for the first, and 0x05 for the second. In the Style file I use: (highway=tertiary | highway=tertiary_link) [0x00 road_class=3 road_speed=3 resolution 23-21 continue] (highway=tertiary | highway=tertiary_link) [0x05 road_class=3 road_speed=3 resolution 24] You can see the result here: http://sites.google.com/site/openfietsmap/zoomlevels The processed map looks cool in Mapsource: thin lines when zoomed out, bigger lines when zoomed in. However, the routing is now messed up (because of the continue statement?) Is there a way to solve this? Another question is how to adjust the road labels, for instance I like to show on the map only the ref. number of the road, like N224 (without using highway plates) and on the tooltip label if I point it with the mouse, streetname (ref) like Zeisterweg (N224). Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] how to differentiate road types with zoom levels?
I already found the answer to my own question, and it was easier then I thought (highway=tertiary | highway=tertiary_link) [0x00 resolution 23-21 continue] (highway=tertiary | highway=tertiary_link) [0x05 road_class=3 road_speed=3 resolution 24] I only removed the routing rules in the first line, and now it seems to work... Haven't tried it yet on the gps, but it seems promising :-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with display of streetname labels
I tested my TYP file again and again. Now I narrowed the problem down to setting the extended label to invisible on some line types. All streetnames dissappear only with routable roads (I think). If I set the railway labels or admin. borders to invisible, streetnames still show up (this behavior happens only on certain gps models, not on Etrex, nor on Mapsource - the only remedy to correct this is a hard reset of the unit). Can anyone with Nuvi/Oregon/Colorado/Dakota type of GPS confirm this behavior or is there something else wrong, maybe in my Style file? I tried to make a TYP file with maptk, but there this happens too. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Routable pedestrian areas
On my Openfietsmap a routable cyclemap of the Benelux, I use in the style file highway=pedestrian area=yes [0x08 road_class=0 road_speed=0 resolution 22 continue] It routes via the borders of pedestrian areas for pedestrians, so whats the difference with this patch? See http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/Styles/lines for my style definitions. Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Routable pedestrian areas
Well, I compiled the map with version 1620, and on my map the outlines of those pedestrian areas are rendered as footway, and are routable (dotted lines). The polygon is rendered grey. See a screenshot of my map at http://img249.imageshack.us/img249/993/dam.jpg The osm data of this square: http://www.openstreetmap.org/browse/way/34132635 IF those are connected to other roads, you can make a good routing already without a patch. In my style file the continue statement makes sure the pedestrian roads are rendered (as footway) as well as the area. Minko Marko Mäkelä wrote An educated guess: you cannot translate the same way to both a polygon (area) and a line, or can you now that the style branch has been merged to trunk? I would prefer to see this in the style file. The fewer hard-coded tweaks in the mkgmap core, the better. Is there now a way to implement the oneway-cycleway duplication in the style file? If there is, could the current code be removed from the core? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search icon behavior varies in some gps units
Address search doesn't work either on a Nuvi 310 and Dakota 20. Probably the same for Oregon/Colorado models. It pops up with a question of state/province and then it finds nothing. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Routable pedestrian areas
Felix, -routing over areas works for me. -about my e-mail client: I read this list from the web at http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/maillist.html I'm not subscribed to individual messages because of the high volume. I can't find a button to reply directly to the list. There is a reply button but it only sends the reply to the person who posted the message, and if I click on it, it doesnt go to my web email. So I have to copy and paste the message everytime to my web-email and this sucks. I can't figure out to do it on another way, sorry ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Description text
Hi,
It would be great to be able to add more information to the pois.
At the moment the information that can be seen is streetname, number, postal
codes and placenames
in the properties of some of the pois (the gps can't show this properties box
on all kinds of pois unfortunately)
I have been experimenting to 'fool' my Garmin to use addr:streetname etc for
some other information and this trick worked.
tourism=information
{
add addr:street='${opening_hours}';
add addr:postcode='${website}' ;
add addr:city='${note}' ;
} [0x resolution ..]
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] pois and wrong citynames
Hi, In all pois that can contain extra info fields for address information, a default city is automatically created by mkgmap (if it isn't already there in osm). Sometimes those place names contains the wrong cityname, so I wonder if there is a way to lookup a more correct cityname from the polygons style file, before this mkgmap process kicks in. For instance, I would like to add a statement in the points style file like addr:city which looksup the correct city name from the polygons style file, if a poi that lies within a polygon with the tags place=city/town/village (or boundary=city/..) or even landuse=residential (with a name). Or maybe even from multipolygons created from administrative boundaries (like municipalities)? For my custom map, I created transparent polygons for those areas, and in Mapsource the name of place=city etc shows up if I point with the mouse to a certain area within the polygon. So I wonder if it is possible to combine those names with the pois. Any ideas? Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maintaining generated sea polygons
Hi, I don't know if this is the same problem as Nop described, but lately I found that on my map some sea areas were gone in the Netherlands: see http://img338.imageshack.us/img338/9992/errorcoastline.jpg On osm it looks ok: http://www.openstreetmap.org/?lat=52.817lon=4.955zoom=10layers=B000FTF Im using the geofabrik abstract from europe to compile my benelux map, Any idea how to fix this? I tried another abstract (planet-benelux) but this gave the same results. Is it caused by the splitter? Is it an error in de osm data? In the mkgmap args i use generate-sea: no-mp,extend-sea-sectors,close-gaps=1000 and it never went wrong except for the last two weeks. Nop wrote: Hi! I have been playing around with generated sea polygons. The algorithm works remarkably well - but I have been experiencing trouble due to inconsistent use of natural=coastline in the data. There was an invalid use of natural=coastline in the planetfile, that caused a whole tile in the Alps to be flooded. So I tracked it down, fixed it and waited for the next planetfile. This time another tile near Berlin was flooded. I tracked it down, noted that another mapper had already fixed it and waited for the next planetfile. This time another tile south of Würzburg was flooded... - you note the pattern? :-) For three weeks I have been unable to grab a planetfile with correct coastline for central europe - they are broken at about the same speed we can fix them. So even though I was able to build a really nice map a while ago, all update attempts were broken. Therefore my question: Would it be possible to save the generated sea polygons to disk in osm format so an intact set of polygons can be re-used with future osm data? That way it could be ensured that future updates will have the same, correct sea polygons and not be randomly broken by temporary inconsistencies in the osm data. Storing the image files and using them as a seperate map layer is not a solution as older Garmin devices are really cumbersome with layers or cannot handle multiple layers at all - and the map is for an older device. Any ideas? Nop -- View this message in context: http://gis.638310.n2.nabble.com/Maintaining-generated-sea-polygons-tp5082865p5082865.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] Debugging generated sea polygons
I have found the bug with the geofabrik osm inspector: http://tinyurl.com/3aaz6wp Removed a duplicate coastline and now it renders fine :-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Maintaining generated sea polygons
Hi, I have found out that in my case it was not caused by the splitter, but a mistake in osm: a coastline placed on top of another one. I removed the last one and now it renders fine. Werner wrote: I used splitter and mkgmap to compile a map of Finland, based on geofabrik- data. The map was defective: For example, Savonlinna was flooded; on the other side, some lakes in the Saimaa- region were displayed as land, their islands as lakes. IN THIS CASE, the splitter caused the errors: Increasing the overlap- parameter from 2000 (which is default) to 8000 solved the problem. Werner ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] routing errors on temporarily closed roads
Hi,
In the default styles, mkgmap has some routing problems with roads that are
temporarily closed with the tag access=no For instance, this problem can
occur on cycleways which are closed to all traffic (bicycles as well) because
of road reconstructions. In the default style the handling is
highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x16
road_class=0 road_speed=1 resolution 23]
If someone is adding the tag access=no on osm to mark this way temporarily
closed, mkgmap ignores this rule because it gives all cycleways by default a
tag bicycle=yes (which allows bicycle routing on this street, even access=no).
Maybe its better to check first if there is already a tag access=no, and if so,
set bicycle=no?
Something like this?
highway=cycleway access!=no {add access = no; add bicycle = yes; add foot =
yes} [0x16 road_class=0 road_speed=1 resolution 23]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routing errors on temporarily closed roads
Marko wrote:
I believe you would need something like this, so that you get to see the
temporarily closed ways on the map:
highway=cycleway (access!=no | access!=*) {add access = no; add bicycle =
yes; add foot = yes}
highway=cycleway access=no [0x16 road_class=0 road_speed=1 resolution 23]
Can you please test this? If it is OK, I am happy to commit it.
access!=no is already covered by access!=*
And what if highway=cycleway and access=private? Then the road is not shown
Maybe this should rather be:
highway=cycleway access!=* {add access = no; add bicycle = yes; add foot =
yes} [0x16 road_class=0 road_speed=1 resolution 23]
I tested this with
highway=cycleway access!=no {add access = no; add bicycle = yes; add foot =
yes} [0x16 road_class=0 road_speed=1 resolution 23]
Then the routing works fine. Foot=yes should be maintained, at least in NL's
walking is allowed on cycleways.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] natural=sand / natural=beach / surface=sand
Proposal for adding natural=sand to the default mkgmap styles. The tag natural=sand is commonly used in the Netherlands for extensive areas of so called drift-sand (Dutch: zandverstuivingen, in osm on 300 ways/relations), which are unique in Europe. Can be rendered the same as natural=beach, which isn't rendered as well. Also surface=sand (used in polygons) can be considered to this group. Maybe the garmin type 0x53 (sand, tidal mud) is suited for this group, but I don't know how badly this will appear on Garmin/Mapsource (blue?). Since I'm using a TYP file it isn't my problem ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing does not work since December.
For my openfietsmap I'm using mkgmap v. 1647 and I have no problems with routing on those same dutch bikepaths at all, as well as a lot of other happy users of my maps (a few hundred?) Also on Mapsource it works ok (as long as the distances are not too long, 20km) Valentijn wrote: Hi Paul, Since r1431 (2009-12-10) bike routing has, IMHO and for my situation, degraded. When I'm building biking maps for the Amsterdam region, I'm using a style file from r1430. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] some questions about splitter and europe extract
Thanks Aighes, It now worked, splitting time was much faster (about 1 hr to extract the europe.pbf with osmosis and another hour to split the benelux.osm file). Cheers, Minko Aighes wrote: Hi, splitter r123 only reads osm-xml format. So you have to use in osmosis --write-xml. I don't know, when a new version of splitter will be released, but I hope it will be soon. Because diskspace will be reduced enormously, is you can use the binary format. aighes ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option generate-sea buggy
Maybe it's caused by the geofabrik extract of germany.osm because I notice the same problems happen for the same region (near Emden) if I use the Benelux abstract from planet.openstreetmap.nl For my Benelux maps I have use the europe.osm extract from geofabrik and then split it with a wider border area. (It was me who reported an error with the coast line on the openstreetmap forum, but this has already been fixed last week). Maybe the German extract has a border area that is too small so some coastlines get broken? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option generate-sea buggy
Hi Josef, Do you use the bzip2 or the pbf binary format? The pbf is smaller (3,6gb) and it doesn't take that much time to cut out an extract for the benelux with osmosis. Josef wrote: As Minko I use now europe.osm and cut out a rectangular piece with osmosis. Map is now good. The disadvantage is, that I have to download 5,4 GB instead of 1 GB and creating the map takes half a day instead of one and a half hours. I wrote the problem to geofabrik. Thanks Josef ___ 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] TYP file for default mgkmap
I wonder if anyone has a TYP file available for the default mkgmap styles. If i download the world osm routbale map from Lambertus' site at http://garmin.na1400.info/routable.php the colours and symbols in Mapsource are not displayed very well (horizontal brown stripes representing forest, yuck!) I know this could be represented a lot better with a simple TYP file (Garmin uses nowadays also Typ files for the city navigator etc) and since the routable garmin osm maps will be of the killer apps of the osm community is there a TYP file out there that could be implemented in the standard mkgmap? To give an example, I put two images on http://sites.google.com/site/openfietsmap/osm-1 The first one is the default mkgmap of a region in the Netherlands, the second one my openfietsmap with a modified mkgmap style and TYP file. On osm there are more such styles, like the mapnik version which look very pretty: http://wiki.openstreetmap.org/wiki/User:Petrovsk/FR:My_Garmin_map_styles http://blog.lionelmaraval.fr/post/2010/01/23/Carte-pseudo-mapnik-pour-Garmin So any ideas to improve the layout of the mkgmap styles with a typ file would be recommended. Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP file for default mgkmap
In order to find a good TYP file for the default mgkmap styles, I found the mapnik.TYP from Petrovsk (1) very useful. Because some areas were not rendered very well, I modified a few things and put it here to download (2). For instance he uses solid bitmaps for rendering areas, where transpararent bitmaps looks better. Residential areas were rendered like campgrounds but maybe the style files are a bit different or they were changed. I only changed a few things in the original TYP file (polygons for forests, campground-residential and farmland). The results can be seen here (3) I noticed there are a few things not rendered at all in the standard style: -landuse=grass for instance -highway=cycleway is rendered as footway etc I would like to hear your opinion if there should be a standard TYP file (like mapnik) or why not. Minko (1) http://blog.lionelmaraval.fr/post/2010/01/23/Carte-pseudo-mapnik-pour-Garmin (2) http://mijndev.openstreetmap.nl/~ligfietser/diverse/mapnik.TYP (3) http://sites.google.com/site/openfietsmap/osm-1 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Changing styles and TYP integrating
Putting your TYP file at the end of the mkgmap command should work, I think... I have also some suggestions/comments to the default style: Lines: highway=pedestrian (roadtype 0x06) has the same line type as unclassified roads, why? Garmin has also a line type 0x0d [Pedestrian area] which is routable as well. a suggestion could be to change this into 0x0d or the same as footway, 0x16 In my custom styles I use type 0x0d for footways, paths, pedestrian ways and they route fine Line Type 0x16 can then be used for cycleways, which are now rendered the same as footways in the default style. Other line types that are routable can be used as well to distinguish more type of highways that are rendered the same in the default map: 0x0e 0x0f 0x10 0x11 0x12 0x13 Think about bridges, tunnels, steps etc Polygons: add landuse=grass to landuse=meadow add natural=heath [0x20 resolution 20]? add natural=sand | surface=sand to natural=beach I wrote earlier about a proposal to put some kind of standard TYP file to the default styles. The Mapnik ones from Lionel aka Petrovsk are suitable for this and he already give his permission to enhance it. Maybe this can be worked out and translated it into German, English etc Thanks, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error splitting binary files
I tried to split an extracted area with osmosis too. Same errors. I suppose you need to set osmosis to --write-pbf in order to get a binary abstract? aighes wrote: Hi I know, it wont help you, but I haven't nay problems with pbf-input and modified area.list. I think the only think I do divernt is splitting the europe-file with osmosis to the needed size. aighes ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flood blocker
How about highways on dikes or dams? http://www.openstreetmap.org/?lat=51.66033lon=3.72579zoom=16layers=M ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error splitting binary files
Hi, I tried it again, splitted then europe.pbf now without osmosis and without errors. So i don't know what went wrong the first time. The benelux took me now only 50 minutes (instead of many hours with the bzip2 file) Thanks, Minko Ralf wrote: I have splitted the europe pbf extract successfully without osmosis and with a pre-generated areas.list. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] rendering roundabouts
Can nobody explain why those jagged lines occur in those roundabouts? Is it because the grid of garmin is too rough and mkgmap makes mistakes aligning the nodes in a circle? I wrote: I noticed that some roundabouts are rendered very badly, like this one: http://img153.imageshack.us/img153/1677/rotonde.jpg http://www.openstreetmap.org/browse/way/81912267 Can I improve the rendering by changing some settings (reduce-point-density, merge-lines or remove-short-arcs)? Or is it just the way those roundabouts are mapped that causes this behaviour? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] rendering roundabouts
Yes, this one for instance: http://tile.openstreetmap.nl/?zoom=18lat=52.1696lon=5.39063layers=B00 http://img137.imageshack.us/img137/1024/rotonde2.jpg It has nodes every 10m or so, so I think I'll recommend it to the guy who draw that roundabout instead of every 30cm ;-) Thanks! Minko WanMil wrote: Do you have any roundabouts that look better? I suppose that the low precision garmin coordinates are the reason for this. I cannot give precise values but I think I remeber that the precision is sometimes less than 4 meters which means two distinct points have at least a distance of 4 meters. Otherwise they are mapped to the same coordinate. 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] rendering roundabouts
On the dutch osm forum this particular roundabout has raised some questions about how mkgmap deals with filtering those nodes. Does it calculate an avarage position of a cluster of nodes that are (too) close to each other and group them into one node? Is this the reason why those jagged lines show up on the garmin img? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] rendering roundabouts
Yes, I'm using remove-short-arcs. If I don't use it, mkgmap generates a lot of error messages. However, the roundabouts with too many nodes remain jagged like a drunkard has mapped them ;-) If I specify remove-short-arcs with a high number (say 5 or 10) the results gets worse. - Oorspronkelijk bericht - Van: Marko Mäkelä Are you using the option remove-short-arcs? I do not know how it works, but in the worst case, it does not calculate any averages, but just merges nodes that are too close together, until no too-close nodes remain. A random node would end up being selected as the representative of the cluster. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] rendering roundabouts
Thanks Johann, I already tried several settings of reduce-point-density, but this seems to have no effect on the shape of the roundabout at all. Regards, Minko ___ 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] error splitting binary files
I'm having problems with splitting the latest europe.osm.pbf extracts from geofabrik (5 6 dec). After 25 sec the splitting seems done, normally it would take one hour. I have tried a smaller section too (Belgium.osm.pbf) but that looks fine. I'm using Splitter 161. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] increase precision of node coordinates?
Hi Maks, I think it's a Garmin problem, the resolution of the Garmin's are not as fine as on Mapnik. See also this subject which is quite related to your question: http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07459.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error splitting binary files
Thanks, I'm following the discussion on talk-de. I just splitted netherlands.osm.pbf (08-Dec-2010 02:40) and it seems all the relations are gone. Lines and polygons are ok. I also mailed Frederik about this. The splitted europe.osm.pbf (benelux area) from today showed only some pois. BTW im using windows. aighes wrote: It seems to be an error in extract-file. Osmosis has also problems Frederik is informed about it (talk-de) and will take a closer look to it. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
I tested the floodblocker on the Benelux abstract from http://planet.openstreetmap.nl/ The options in my mkgmap args file were: generate-sea: multipolygon,floodblocker,land-tag=natural=background The parameter fbgab gives an error (I'm using java under windows). I tried different settings for fbthres,fbratio but no sea came back on my map. See the results here: http://img155.imageshack.us/img155/2873/bnlj.jpg Only one tile where the sea remained, the rest was completely gone. This is how it looked without the floodblocker: http://img33.imageshack.us/img33/8382/52519932.jpg Mkgmap settings are generate-sea: no-mp,extend-sea-sectors,close-gaps=1000,land-tag=natural=background Not good either but still the sea is there (too much sea though). Usually I use the europe.osm.pbf extract and split it, without problems of flooding. Since a few weeks there are problems with the europe pbf file under windows, so I have to find an alternative. The Benelux abstract from http://planet.openstreetmap.nl/ shows flooding because it lacks some German coastline, in particular this way is not part of it: http://www.openstreetmap.org/browse/way/4102027 I hoped that Wanmils floodblocker could solve this but it unfortunately it couldn't. Is there another way to merge this coastline to the splitted osm tile? Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
Sorry Felix, but I have read your message. you wrote: I just noted, the multipolygon mode does not work. The floodblocker does not seem to show any effect I used multipolygon, because Wanmil adviced me to do so, because otherwise the floodblocker didn't work. So, I did, and I noticed the floodblocker did his job very well. All the sea except one tile disappeared. Thanks for your advice, I will test it now without the floodblocker option and with extend-sea-sectors (without no-mp). Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture: http://img404.imageshack.us/img404/3702/nogroningen.jpg The tested tile you can download at http://mijndev.openstreetmap.nl/~ligfietser/diverse/Test.zip ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
Thanks Wanmil, Those images explained very well what exactly happens. So what I can do is to add more coastline to the benelux osm data to prevent that this coastline is intercepting itself. I have to merge osm data (German coastline) to the osm data from the Benelux extract. How does this work with osmosis? Or is it possible with mkgmap to combine the coastline with osm tiles? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
That will be great! I suppose somebody already uses this option? Is there a German coastline available? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Configurable flood blocker
Hi Wanmil, Just letting you know I solved the floodings problem. My tile borders stretched too far east, far beyond the extract. By ending it more to the west, the sea disappeared :-) I even didn't have to use a floodblocker. Thanks for your help! Minko - Oorspronkelijk bericht - Van: WanMil wmgc...@web.de Aan: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Verzonden: Vrijdag 17 december 2010 18:30:48 Onderwerp: Re: [mkgmap-dev] Configurable flood blocker Thanks Wanmil, Those images explained very well what exactly happens. So what I can do is to add more coastline to the benelux osm data to prevent that this coastline is intercepting itself. I have to merge osm data (German coastline) to the osm data from the Benelux extract. How does this work with osmosis? Or is it possible with mkgmap to combine the coastline with osm tiles? You can load a separate coastline file using the option coastlinefile=coastlines1.osm.pbf,coastlines2.osm.pbf When using this option the coastlines of your tiles are ignored and are only taken from the given file(s). The file(s) need not contain only coastlines but I think using the complete original benelux and german files here will not be possible due to memory problems. You can use osmosis (please read the osmosis documentation!) to extract the coastlines. The osmosis call might look like: osmosis.bat -rb europe.osm.pbf -tf accept-ways natural=coastline -tf reject-relations --used-node -wb europe_coasts.osm.pbf WanMil ___ 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] error splitting binary files
Hi, Any news about this problem (which still exists)? aighes wrote: It seems to be an error in extract-file. Osmosis has also problems Frederik is informed about it (talk-de) and will take a closer look to it. aighes -- View this message in context: http://gis.638310.n2.nabble.com/error-splitting-binary-files-tp5758967p5811383.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] error splitting binary files splitter is extreme slow
Until 2 Dec. everything went ok with splitting the binary europe extract. Splitting took me about 1 hr on a modest laptop (windows vista). After 2 December there were some problems with the country extracts as well, but they were solved. It looked like they did some changes with the europe.osm.pbf because since that date I'm not able to split it anymore, nor with splitter nor with osmosis. When I try to split the europe.osm.pbf only pois are extracted in a few minutes time. Since the introduction of the pbf file something got changed with the europe.osm.bz2 extract as well. Normally it took me about 2 hrs to split the data, but since october they published the pbf file, splitting times of europe.osm.bz2 extract went up to 7 hours! See also http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07071.html - Oorspronkelijk bericht - Van: Henning Scholland h.scholl...@googlemail.com Aan: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Verzonden: Vrijdag 24 december 2010 11:37:32 Onderwerp: Re: [mkgmap-dev] error splitting binary files Hi It was discussed on osmosis-dev ML. There was just a differenc in some bytes in the beginning of a working file and the not working file of Geofabrik. The part which includes the data was exactly the same. No one knew why one file doesn't work on windows. Regards, aighes ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Hi Steve, Mapsource crashes when I click on the search button. I removed code-page: 1252 from the parameters but it didnt help. Mapsource also crashes when I try to send the selected map to the GPS I used mkgmap-index-r1778.jar on a windows vista 32bit machine Mapsource v.6.16.2 Mkgmap args see http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.args Hope this helps, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes. Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mult- language in style files
Hi, Is it possible to add several languages to the default_name tags in the style files? I know it can be controlled in the TYP file, but if I use one Garmin type for several polygons, for instance for type 0x19 I use: leisure=pitch sport=soccer [0x19 default_name=voetbalveld resolution 23] landuse=recreation_ground [0x19 default_name=recreatie terrein resolution 22] leisure=playground [0x19 default_name=speeltuin resolution 24] My Benelux maps are used by Dutch, German and French native speakers Since I'm not able to offer 3 different maps, is there a way to set the default_name in different languages, like default_name:eng=soccerfield; default_name:nl=voetbalveld etc I have tried this but that didnt work. Is it possible by some kind of regular expression? Thanks, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
I found the reason what made my mapsource crashing (bad map id) when I clicked on the address search button. . The cause I have found in my mkgmap args file: mapname: 30010040 description: testmap input-file: 10010040.osm.gz It causes mkgmap to crash if I search for adresses. I thought it was caused because I used mkgmap-index-r1778.jar but it happened with other mkgmap versions too... Another test didnt cause a crash: mapname: 10010040 description: testmap input-file: 10010040.osm.gz So in my args file I noticed that it matters that at least the first input file and the mapname file must have the same map ID? I also found out that if I put a (already processed) contour img first before the osm tiles, the same crash happens (bad map id) if I click on the address search button: # contour lines first description: contourmap input-file: 10010101.img # osm tiles last mapname: 10010040 description: testmap input-file: 10010040.osm.gz However, this causes a crash in MS (address search button), but it doesnt crash if i put the osm tiles first: # osm tiles first mapname: 10010040 description: testmap input-file: 10010040.osm.gz # contour lines last description: contourmap input-file: 10010101.img Note that I don't put the line mapname: 10010101.img in the line above with description: contourmap because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the contourlines. I don't know if my findings are related to the address search problem, but maybe it helps. Cheers, Minko - Oorspronkelijk bericht - Van: Minko Aan: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Verzonden: Dinsdag 11 januari 2011 13:21:48 Onderwerp: Re: [mkgmap-dev] Improved street search in index branch Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes. Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improved street search in index branch
Yep, it works now, no more crashes! Steve wrote: @Minko: can you confirm this is your problem? ..Steve ___ 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] contour lines (was: Re: Improved street search in index branch)
Yep Charlie, I recently discovered that after struggling two years ;-) My workaround until now was to save the contour img's as mp files. Only that way it was displayed correctly. Now I know we just have to leave the line mapname: ... out of the args file. Like Felix adviced, levels must be the the same, and the map numbers were higher with my maps as well. I also found out recently that the --show-profiles=1 option works now within the map (thought it only worked with a separate contour file map, not a combined one). Cheers, Minko - Oorspronkelijk bericht - Van: charlie No way! Is this why I can't get contour lines to display in MapSource (even though I know they're there because I can see the contour elevation labels)??? I'd given up on ever getting contours to work properly in MapSource. Prize for obscurest workaround of the year so far if this works. ;) -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New splitter build for pbf format
Tested splitter-r161-3 on the latest europe.osm.pbf, it is working now, thanks! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] issues with overlapping maps
Hi, There are some issues with two maps that I'd like to display on a Dakota GPS: Openfietsmap Benelux (OFM_NL) and Germany (OFM_DE): http://img209.imageshack.us/img209/3628/ofmh.jpg -The German map is built from a Geofabrik Germany abstract, -the Dutch map is built with the Geofabrik europe.osm.pbf. -Both maps have a different FID but the same draw order. The problem lies in the empty background of the Germany tiles. If I send some selected tiles to my GPS, sometimes the 'German' Northsea floods the Dutch areas (depending on the zoom level). When I zoom in, the sea disappears but the pointer doesn't show the streetnames etc. It seems only to see the background map. If I point it to an area where both maps don't overlap, it shows the name or type of the osm features. The odd thing is that this only shows up in a Dakota/Oregon. On a nüvi I don't have those issues at all. If I change the draw priority of one of the maps, cities and towns on the other map are not searchable anymore. Also a gap appears between the two maps if the draw orders are not equal. It doesn't make any difference if the maps are selected or not. (This weird behaviour only shows up on the Dakota and Oregon types, on a Nüvi deselecting the map DOES make a difference). The mkgmap args file is listed here: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.args Maybe this option has to do with the background problems? generate-sea: extend-sea-sectors,close-gaps=6000,floodblocker,land-tag=natural=background The maps can be downloaded here: http://sites.google.com/site/openfietsmap/downloads Regards, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Changing styles and TYP integrating
Marko Mäkelä wrote: Your suggestion of replacing the 0x06 with 0x0d makes sense, provided that it is routeable and does not imply bicycle=no. (In Finland, bicycling up to 20 km/h is allowed on pedestrian areas.) Yep, I use type 0x0d for different lines (mainly tracks, mtb-paths and pedestrian roads) and cycling routes very well on these roads. a suggestion could be to change this into 0x0d or the same as footway, 0x16 How would you identify a footway? There is some path/cycleway/footway controversy and ambiguity going on. Something like this? highway=footway bicycle=(yes|designated|permissive|official) [ 0x16 ] highway=footway [ 0x0d ] # other cases than the above highway=path bicycle=no [ 0x0d ] highway=path bicycle!=no [ 0x16 ] highway=cycleway [ 0x16 ] I would suggest highway=path bicycle=(yes|designated|permissive|official) [ 0x16 ] highway=path [ 0x0d ] so the same as footways As far as I know on the Dutch map highway=path is a narrow trail in forests or on fields that are not suitable for cycling unless otherwise stated (with bicycle=yes, for mtb trails etc). Right, it could be useful to distinguish cycleways (or foot-and-cycleways) from foot-only ways. Yes, that would be great. Other line types that are routable can be used as well to distinguish more type of highways that are rendered the same in the default map: 0x0e 0x0f 0x10 0x11 0x12 0x13 Think about bridges, tunnels, steps etc I am a little reserved about this, but I agree that this could be useful with a TYP file. I agree, someone has to maintain a default style file first otherwise it wouldnt make much sense. Polygons: add landuse=grass to landuse=meadow add natural=heath [0x20 resolution 20]? add natural=sand | surface=sand to natural=beach According to http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types the 0x20 could work, but I would have to test it. There is no natural=beach in the default style. What did you have in mind? 0x53? sand/tidal/mud flat - although it looks like water in gpsmapedit :( I wrote earlier about a proposal to put some kind of standard TYP file to the default styles. The Mapnik ones from Lionel aka Petrovsk are suitable for this and he already give his permission to enhance it. Maybe this can be worked out and translated it into German, English etc I can help with a Finnish translation. How would this TYP file be maintained? Is there some editable (text) format and an editor that is free software? Quite a while back, I was toying with the idea of composing a TYP file from an assembler source file, but I never got around to completing it. I use typviewer from http://opheliat.free.fr/michel40/ to convert a typ file into txt format and back to typ which is also compatible with the online typ file editor from ati.land.cz Drawback is that it's only available in French. I don't know who is willing to maintain the default typ file. The main problem is that there is a big difference in display between the older Garmin units and the 'touchscreen units' like Oregon, Dakota and Nuvi, see http://forum.openstreetmap.org/viewtopic.php?id=10032 For my cycling maps I have a workaround for the older units with thin lines and a green backgroud. Anyway, I think the mapnik.typ that is now available is always better than no typ file at all. Regards, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Changing styles and TYP integrating
I think we also need to look what kind of definitions Mapnik is using. The default mkgmap Garmin map should look the same, in order to prevent that some cycleways on the Garmin are footways on mapnik. Sorry about the tracks, better leave highway=track displayed as track, if the track is actually a compulsory cycleway, it had to be mapped as highway=cycleway with surface=unpaved instead of highway=track with bicycle=designated. I dont think its mkgmap task to interpret things like 'if highway=track bicycle=designated, lets make it a cycleway'. On my cycling map it's a bit different, because my goal is to show cyclists which roads are suitable for cycling. On my map I need to display highway=track bicycle=designated as cycleways (dotted red lines for unpaved, solid red lines for paved). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Changing styles and TYP integrating
Advantage of the mapnik.typ is that it looks like the 'default' osm map. Disadvantage are the ugly borders on (non touch-screen) older units. Have you got an example of another Typ file that looks good on the older units? For my cycling maps I've made two typ files, one for older units with very light grey borders. White unclassified roads are still visible because I use a light green background. If you use a white background, 'white'roads are not visible without border or on a yellow background the tertiary 'yellow' roads are not visible without border. I don't know where Mapniks drawing rules can be found. If the 0xd works like this on all units, I would translate cycleways to it in the default style. The current 0x16 (brown dashed line) would be for footways and paths that are not (primarily or at all) for bicycling. 0x0d on a nuvi and a Dakota: without a typ file they are thin white lines with line as label. On a white/grey background almost invisible. :-( On a nuvi 0x16 are thin grey lines. On a Dakota it's a thicker, grey dashed line, same as unpaved roads. This shows once more a typ file is absolutely needed to keep up with the changes on osm. Regards, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Distinguishing cycleways from footways and minor paths
Marko, I think it's a good idea to display cycleways as 0x07 (alleys according to garmin). I treat pedestrian the same as footway too, because many mappers use one of these for exactly the same roads. How about highway=service? I suggest to display them as type 0x06. Maybe with a default_name=service? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and long way-segments
Henning, Did you try a higher overlap setting? Maybe --overlap=6000 ? --overlap Nodes/ways/rels that fall outside an area will still be included if they are within this many map units. Default is 2000 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] crash. Too many tiles?
Hi Valentijn, Here is an easy fix: the performance gets worse the smaller the tiles get. With max-nodes=150 I am able to split the Netherlands in a way that mkgmap didnt get stuck on too many nodes, and the routing is better in comparison with more tiles and max-nodes=100 Tested it on a Dakota which routed from my home town to Oldenburg in Germany without any waypoints in between (260 km!). -- Valentijn wrote: (The reason for this many tiles was the idea that a Nüvi might get better bike performance on long distances if the number of data to unpack (i.e. individual tiles) would be smaller - because of the smaller tiles. Might be just a stupid idea, I don't know, I was going to check but we might never know now... ;) So I'm just passing this on, for the sake of it, don't look too long at it because it's probably not worth it; but if there's an easy fix, it is welcome ;-) Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 0x10 for residential in default style
Hi Jeroen In your lines style I see 30 lines of code to render tunnels [0x12]. You could do this with one line as a layer on top of each highway: (tunnel=yes | tunnel=true) (railway!=subway | waterway!=*) [0x12 resolution 23 continue with_actions] This way you don't need to specify each road with a tunnel tag separately. In the typ file it is rendered as a transparent bitmap with two dashed lines with enough space in between to render the highways: - - - - - - - - tunnel=yes [0x12] ___ ___ highway=primary [0x01] - - - - - - - - - Oorspronkelijk bericht - Van: Jeroen Muris No, I don't know this problem - a least not on my device (Oregon 550T). But the definitions in my TYP file cause the line to be much narrower - combned with the style definitions they almost never overlap. I just checked, and when I zoom out with a 'crowded' style, the device leaves out the borders of the lines completely - thus avoiding the problem. And where different types of ways meet at normal zoom levels, the ends are 'blended' most of the time. But is someone want me to test another *.img file, I'm happy to oblige. Regards, J-. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bug in mapsource installer
Hi, I have a question about the nsis mapsource installer. I notice in the nsi file the series-name generated to set the default name for installing the maps in the mapsource register and the default installation folder: !define DEFAULT_DIR C:\Garmin\Maps\OpenFietsMap (series-name) !define INSTALLER_DESCRIPTION OpenFietsMap (series-name) !define INSTALLER_NAME OpenFietsMap (series-name) !define MAPNAME test !define PRODUCT_ID 1 !define REG_KEY OpenFietsMap (series-name) Why is this not the family-name? In the map dropdown list in Mapsource, I would like to see the mapname with creation date, (which is the series-name). The default directory and Mapsource registers should be kept the same mapname every time, usually this is always the family name. Can this be changed? Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Base map interfering with routing
Looks like I have the same problem now. :-( I was testing a map created with mkgmap-r1827. It was a combined map with tiles from two mapsets with different family ID's (The Netherlands and Germany). With mkgmap I copied a few img's to a different directory and created a new map with another FID. It looked good in Mapsource. Then I send it to the Nuvi. I searched for Osnabruck and started to route from Enschede. Since then the route navigates only via the Basemap, not the osm map anymore. Tried to rename the basemap, but then routing isnt possible anymore. Hard resetting the unit: no solution, it keeps routing via the basemap. If I turn CN on, it follows the CN roads, so that looks ok. I tried different and older osm maps, but it still routes via the basemap. I replaced CN (a gmapsupp.img) by another gmapsupp.img (osm map) on the internal memory card but it didnt seem to navigate via the osm roads, just the basemap. This doesn't look good. Maybe it has to do with the latest revisions? (mkgmap-r1827). I have tried this before with other mkgmap versions but never had such problems. Regards, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Base map interfering with routing
After reflashing the firmware the routing problems have gone ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style + TYP, next iteration
Jeroen wrote: - other paths were green, now yellow On a yellow background? Hard to see I guess ;-) You can try to use extended line types like 0x100/00-1f 0x101/00-1f etc Note that even with a typ file some of them will not show up on some devices, and they are not routable. See my typ files on http://openfietsmap.nl ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
Good to hear that the mystery about the address search is revealed. :-) I made a test map with mkgmap-index-r1850.jar a 9 tiles, mainly in NL and one tile partly in Germany (area of Emmerich am Rhein). Send it succesfully to the GPS (Dakota and Nuvi). Here are a few test results: Used country-name=Nederland country-abbr=NL. Address search on the GPS works! Address search shows two options: Spell country and Nederland Spell country shows: Deutschland and Nederland Searching for a place name with E in Deutschland shows a few place names, starting with E, like Ellecom, DEU but this place is not in Germany at all. http://www.openstreetmap.org/browse/node/44948760 If I search for Ellecom in the Netherlands: not found. Searching for Emmerich am Rhein in Deutschland: not found. Searching for Emmerich am Rhein in Nederland: found Searching for a big place like Amersfoort, which is clearly on the map: not found Searching for a streetname: found, but often located in the wrong place. Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search and index.
Hi Steve, The bug that some street names where placed under the wrong place names already existed with the option road-name-pois (didn't use this option for my last test). Sometimes it even happens if the node with the correct place name is located closer than the wrong place name which is connected to this street. other streets closeby can be connected to the correct place name. See also http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg06206.html - Oorspronkelijk bericht - Steve wrote: Searching for a streetname: found, but often located in the wrong place. It may or may not be the problem, but the fix that allowed tiles to be uploaded to the device will have also in some cases had the effect of making some streets appear in the wrong places. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index branch - Umlaut problem
With a Dakota or Nuvi, Search for a address, city Du - Düffelward, DEU found Enter Street: F-Fährmannsweg-No matches found E-Ehlenstrasse-map is shown So it looks like when there's an umlaut involved it is shown in the index, however it can't locate the street on the map. Minko Chris wrote: Is this problem also occuring on new generation Garmin devices (Nuvi, Oregon, etc.) ? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --make-cycleways labels invisible
Hi, If I use the option --make-opposite-cycleways or --make-all-cycleways, an extra label is placed with street (cycleway). Is it possible to turn this label off or make it invisible in the style line file and how? Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-cycleways labels invisible
PS please ignore the tag opposite-cycleway!=yes that was just a test if rule
one was applied don't use rule 2,
because I thought maybe in rule 1) if oneway is set to -1 it automatically
implies that the next rule will be executed too?
It should be:
highway=unclassified oneway=yes (cycleway=opposite |
cycleway=opposite_lane) {set oneway=-1; set access=no; set bicycle=yes } [0x06
road_class=3 road_speed=5 resolution 22 continue ]
highway=unclassified oneway=-1 (cycleway=opposite | cycleway=opposite_lane)
{set oneway=yes; set access=no; set bicycle=yes} [0x06 road_class=3
road_speed=5 resolution 22 continue]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird behavior and problem with splitter r161
Hi Jean-Marc, Im using an areas.list-file for the Benelux, you can use this to split the europe.osm.pbf See areas_bnl.kml and areas_bnl.list on http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/ I've also made a bigger areas.list that divides the bnl in 3 sections: north, middle and south. First step is to split europe.osm.pbf in 3 big osm.gz files with the areas list below. (or maybe merge middle and south to one big osm.gz). Second step is to split the 3 files into smaller tiles with max-nodes=150 or so. I've made this workaround because I couldnt make a working extract with osmosis either (same problems). # List of areas # BNL-north 3110: 2410496,110592 to 2516992,344064 # : 51.723633,2.373047 to 54.008789,7.382813 # BNL-middle 3120: 2361344,110592 to 2410496,307200 # : 50.668945,2.373047 to 51.723633,6.547852 # BNL-south 3130: 2299904,147456 to 2361344,307200 # : 49.350586,3.164063 to 50.668945,6.547852 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Contour lines in Mapsource (was Improved street search in index branch)
Hi Charlie, I recently noticed that my method of leaving the mapname: etc out didn't always work as expected :-( What always worked for me, was saving the contourlines files as *.mp instead of img with gpsmapedit. My contourlines are transparent but can have the same draw priority. Process the *.mp tiles together with your osm.gz tiles to make img's. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch] MapSource installer improvements v1
The family name is stored in the mapsource windows registry and is commonly used as directory name. It's also the name of the map that you see in your gps. The series name is the name that you see in the drop down list in mapsource. At the moment the series name is used for all the nsis parameters, but I think it makes more sense to use the family name for this. This makes it possible to use the series name in combination with a version or date stamp (eg osm map version 27-02-2011) so you can see in Mapsource from what date your mapversion is (the family name isnt shown in MS). It will also mean that you always store the map in the same folder, because you can keep the family name the same every time. Cheers, Minko -- Steve wrote OK, but this is a bit confusing... it needs to be + familyName = args.get(family-name, OSM map); and then any other change that follows on from that. But what is the real problem here? Do we use the terms family-name and series-name differently from everyone else? (I was never sure which was which). ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Global index branch
Found another bug in mkgmap-r1875. If I search for adresses on a Dakota, and skipping the place name (because often streets are assigned to the wrong place) and enter the streetname, the street is found but it points to a place in the Atlantic Ocean south of Ghana (lat0, lon0). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
Where can I find the help file? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
I've now tested r1877 but noticed almost all the forests in the Netherlands are completely gone at resolution 18 :-( I've tried it with and without --reduce-point-density-polygon but it seems to have no effect. Is there a way to set this parameter off? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
Felix, You have recently introduced so many changes I can't figure out anymore what is causing what. How can I change the settings of drop small polygons? It's not described in the help files. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
Hi Felix, Could you please be more specific. I never had to compile mkgmap before. Is it possible to use an option --drop small polygons for this? The rendering is now far from ideal for the Dutch folks, I would like to turn this option drop small polygons off without having to compile mkgmap. Thanks, Minko Felix wrote: Read rev 1875, and change the 8 to a smaller value. You have to do it in source and compile mkgmap yourself of course. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource installer improvements v5
A few remarks: The Typ file is not registered in mapsource (I think someone already mentioned it, but it is quite urgent to repair this) I dont know where to find / how to access the installer templates. Do I have to compile mkgmap for this? Another thing on the wishlist is to add support for more languages. The other improvements are working fine as far as I can see. Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overlays issue
I'm not sure but maybe the code 0x11f02 isn't supported? I used to do the same with roundabouts but I named it 0x0c04, in my overlays file: 0x0c04: 0x0c, 0x04 This was routing fine. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource installer improvements v5
PS
Those two lines were missing:
WriteRegStr HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
$INSTDIR\$x.TYP
DeleteRegValue HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
typfile=x.typ
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
Hi, I'd like to see it commited because I want the old layout of the map back. I don't like the 'a quick and dirty approach', the map looks very ugly now at lower zoom levels, shapes look very distorted and forests are completely gone. Am 08.03.2011 14:57, schrieb Minko: Hi Johann, Is this option --min-size-polygon already comitted in the latest mgkmap version? It's seems not working in r.1889. I can't compile mkgmap myself and i'd like to see the old situation back (without deforestation ;-)) No its not commited. I for myself have no write access (and don't want, because than the code gets double checked) to the subversion repository. The patch from this thread is not commited until now. It has to be decided, what we want to be the default value. In my patch the default value would be zero, meaning restoring the old behaviour. Others might argument, that a given value improves the map by removing the cluttering, and for a good map the default should be set to a value. What does the majority think? Comments please. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] s...@mkgmap.org.uk
Thanks, Steve. Could you also commit Nakors latest patch regarding the installer which includes the typ file into the windows register? I think it's quit urgent when you use a typ file (he forgot that in the patch that was commited) Cheers, Minko - Oorspronkelijk bericht - Van: svn commit s...@mkgmap.org.uk Aan: mkgmap-...@lists.mkgmap.org.uk Verzonden: Wed, 09 Mar 2011 23:18:11 +0100 (CET) Onderwerp: [mkgmap-dev] Commit: r1893: Add option to control the smallest polygon that is displayed Version 1893 was commited by steve on 2011-03-09 22:18:10 + (Wed, 09 Mar 2011) Add option to control the smallest polygon that is displayed at lower resolutions. - Johann Gail The default remains at 8, but it can now be adjusted. ..Steve ___ 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] New locator branch
Thanks Wanmil,
I tested a few tiles of the Benelux, and finally I found the street where I
live in the correct city, and not in a neighbourhood village anymore.
Congratulations, you have done a great job! :-)
For the Netherlands, streetnames assign to admin_level=10 or else (if not
specified) assign to admin_level=8 (municipality) works great:
mkgmap:country=NLD mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=NLD mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
A warning that shows up a few times while compiling:
cannot process location element, because it contains no name tag but I don't
know if this is a big issue.
Some test results on a Dakota:
A city was assigned to the wrong Province (Amersfoort, Gelderland, NL)
but the street in this city shows the correct location (Amersfoort, Utrecht,
NL).
Could this be caused by the fact that part of the province polygon of Utrecht
was not
complete in those tiles? Note that this city lies on the border of both
provinces.
As a result, if I look up the street and enter the city first, it finds the
street within the city,
but no results show up if I click on the streetname.
If I skip the city name and enter the streetname directly, it shows the correct
location.
This is not a big issue, since I could skip the region values in the style
files (and I don't care so much about provinces) but I mention it anyway.
For my Benelux map I'd like to know what style definitions works best in other
surrounding countries (Germany, Belgium, Luxemburg)
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS installer improvements phase 2 v2
Hi Nakor, I suppose you need to put this installer template into a installer subdirectory, like 'mkgmap-r1894\resources\ïnstaller\' ? Nakor wrote: To customize the installer script one need to create a resources directory ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS installer improvements phase 2 v2
Is that possible, different maps with the same FID and different PID? I thought only one Family ID can be used in Mapsource. btw, I tried to adapt the template but mkgmap can't find it, where do I have to put installer_template.nsi? I've tried it in a resources folder and in resources/installer but that doesn't work. About the language, the programm asks what language to use, English/French. Then it detects there is an old version already there, the uninstaller pops up, asking again what language you want to use. Maybe it is possible to skip this double check? Thorsten wrote: currently, $REG_KEY will be used to determine if the map is already installed. But $REG_KEY is not unique, if you have several maps with the same family-id, but different product IDs. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS installer improvements phase 2 v2
If you update map_X with FID=x with PID=1, there will be an uninstall.exe in
the folder
of map_X. How would that work with a special layer of that map_X with PID=2 ?
I had a look on your map files, but can't see an installer for the srtm layer.
Let's assume you only want to update the base layer of your map, but not the
srtm layer.
Maybe its better to give the uninstaller name of that base layer (which is now
uninstall.exe) an unique name like uninstall_FID-PID.exe,
so you can choose what kind of map you want to remove.
basemap FID=1000, PID=1, uninstaller name: uninstall_1000-1.exe
srtm layer=FID=1000, PID=2 uninstaller name: uninstall_1000-2.exe
etc
This also makes it possible to install different maps into one directory.
Thorsten wrote
So the registry tree would look like:
${REG_KEY} - ID=Family-ID
|-- {PRODUCT_ID1} - data
|-- {PRODUCT_ID2} - data
|-- ...
And that lead to the next problem: Removing a map from a family,
where still other family members are installed, will remove
the ID tag and thus renders all installed maps of this family useless.
I don't have a solution for that yet.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS installer improvements phase 2 v2
Thorsten, I have now tried to install your bicycle layer, but this gave several errors in Mapsource and the map didnt show up. Duplicated FID, TYP file not found, productcode in registry doesnt match with tdb file. Looks like its not possible to use the same Family ID's on different maps. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS installer improvements phase 2 v2
Thanks Nakor, it worked. Maybe add this to the option help file because it's
not very clear.
Or make it possible to specify another location where the template file is
located in the --nsis option?
--nsis=..\template\template.nsi
More improvements:
If you put a /S when running the installer, you dont get a prompt for
language selection twice:
;Run the uninstaller
uninst:
ClearErrors
ExecWait '$R0 /S _?=$INSTDIR' ;Do not copy the uninstaller to a temp file
Dutch language string:
LangString AlreadyInstalled ${LANG_DUTCH} ${INSTALLER_NAME} is reeds
geinstalleerd. $\n$\nKlik op `OK` om de oude versie te verwijderen of
`Annuleer` om deze update te onderbreken.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS installer improvements phase 2 v2
Small edit in the Dutch language string:
LangString AlreadyInstalled ${LANG_DUTCH} ${INSTALLER_NAME} is reeds
geïnstalleerd. $\n$\nKlik op `OK` om de oude versie te verwijderen of
`Annuleren` om deze update te onderbreken.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
