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] mkgmap index rev. 1809
On 02/02/11 19:04, WanMil wrote: My results with the latest rev. 1820: Compiled Germany geofabrik extract. Mapsource: - All searches work except street search when entering a city name (the selected street is not valid in this map product. Please select a different street.). Even when the city is correct for the street name? For me it is fine as long as the street/city combination exists. When it doesn't exit I see different behaviour on different installations. On one it just shows not found in the result area and on the other it has the 'Please select a different...' popup. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap index rev. 1809
On 03.02.2011 10:35, Steve Ratcliffe wrote: On 02/02/11 19:04, WanMil wrote: My results with the latest rev. 1820: Compiled Germany geofabrik extract. Mapsource: - All searches work except street search when entering a city name (the selected street is not valid in this map product. Please select a different street.). Even when the city is correct for the street name? For me it is fine as long as the street/city combination exists. When it doesn't exit I see different behaviour on different installations. On one it just shows not found in the result area and on the other it has the 'Please select a different...' popup. ..Steve ___ For me it is the same. With 1820 no search for street city and no sending of map to device 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] Distinguishing cycleways from footways and minor paths
On Thu, Feb 03, 2011 at 09:59:14AM +0100, Minko wrote:
Advantage of the mapnik.typ is that it looks like the 'default' osm map.
I think that I would find Mapnik too low contrast on the small screen.
The paleness is useful for overlays, such as www.latukartta.fi (Nordic
skiing tracks overlayed on SlippyMap tiles).
Have you got an example of another Typ file that looks good on the
older units?
No. Until there are open source tools for creating TYP files, I try to
avoid depending on them.
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.
On QLandkarteGT, 0xd..0x14 are totally invisible. This confirms that it
would not be wise to use them without a TYP file.
I think that the default style must be useable without a TYP file. A TYP
file can of course enhance the experience, so to say. :-)
I got another idea: promote cycleways to 0x07 (alley), currently used by
highway=service. On the Edge 705 it looks identical (brown dashed line)
to 0x16, but the default label (shown in navigation instructions and
when hovering the cursor over a way) would distinguish cycleways from
footways and paths. QLandkarteGT distinguishes these by colour: 0x07 is
a brown solid line and 0x16 is gray. Other devices than the Edge 705
might distinguish these too.
What do you think about the attached patch that moves highway=pedestrian
from 0x06 to 0x16 and highway=cycleway and some bicycle=designated ways
from 0x16 to 0x07? 0x07 was previously only used by highway=service and
similar.
If I get no objections in a few days, I will commit this.
Marko
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 1809)
+++ resources/styles/default/lines (working copy)
@@ -58,9 +58,16 @@
{ add mkgmap:unpaved=1 }
# Convert generic path to most specific
-highway=path (bicycle=designated|bicycle=official) {set highway=cycleway }
-highway=path (horse=designated|horse=official) {set highway=bridleway }
-highway=path (foot=designated|foot=official) {set highway=footway }
+highway=footway snowplowing!=no
+ (bicycle=yes|bicycle=designated|bicycle=permissive|bicycle=official)
+{set highway=cycleway}
+highway=path snowplowing!=no
+ (bicycle=designated|bicycle=permissive|bicycle=official)
+{set highway=cycleway}
+highway=path (horse=designated|horse=official)
+{set highway=bridleway}
+highway=path
+{set highway=footway}
# Roundabouts
junction=roundabout highway=trunk [0x0c road_class=3 road_speed=2 resolution 18]
@@ -93,16 +100,17 @@
highway=minor [0x06 road_class=1 road_speed=3 resolution 21]
highway=unclassified [0x06 road_class=0 road_speed=3 resolution 21]
-highway=pedestrian area!=yes {add access = no; add foot = yes} [0x06 road_class=0 road_speed=0 resolution 22]
+# Some countries allow, others disallow bicycling on pedestrian streets.
+# To allow bicycling, add 'add bicycle=yes'
+highway=pedestrian area!=yes {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 22]
highway=living_street [0x06 road_class=0 road_speed=1 resolution 22]
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
-highway=bridleway {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
+highway=bridleway {add access = no; add bicycle = yes; add foot = yes} [0x07 road_class=0 road_speed=0 resolution 23]
highway=byway [0x16 road_class=0 road_speed=0 resolution 23]
highway=service [0x07 road_class=0 road_speed=2 resolution 22]
-highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=1 resolution 23]
-highway=footway {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
-highway=path {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
-highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
+highway=cycleway {add access = no; add bicycle = yes; add foot = yes} [0x07 road_class=0 road_speed=1 resolution 23]
+
+highway=footway|highway=path|highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
highway=track [0x0a road_class=0 road_speed=1 resolution 21]
highway=unsurfaced [0x0a road_class=0 road_speed=1 resolution 21]
highway=road { add mkgmap:dead-end-check = false} [0x06 road_class=0 road_speed=1 resolution 21]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
On Tue, Feb 1, 2011 at 4:20 PM, Torsten Leistikow de_m...@gmx.de wrote: Moin, Henning Scholland schrieb am 31.01.2011 21:41: Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out. Cheers, Ben ___ 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] Replacing --add-pois-to-areas with an add_poi action
Am 03.02.2011 12:51, schrieb Ben Konrath: On Tue, Feb 1, 2011 at 4:20 PM, Torsten Leistikowde_m...@gmx.de wrote: Moin, Henning Scholland schrieb am 31.01.2011 21:41: Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out No, this is a error in osm-data. One object should only taged once. So if you tag this information to a node, you shouldn't tag same info to the polygon. If add-pois-to-area creates an POI, there shouldn't be any node in OSM-data. If there is already a node and so there are two symbols in the map, it's not an mkgmap-bug. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Ben Konrath schrieb am 03.02.2011 12:51: That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out. No, in the OSM data is only a polygon, and AFTER the POI is added to the area, I have the node and the polygon. The style processing afterwards has no chance to detect, whether there is a polygon belonging to the node or not. So in the resulting map I get both, a polygon area and a symbol. For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. But the add-pois-to-areas function is only working on all types or not working at all. And I can not remove such types from the point style, because in the OSM data there are also nodes of the same type without a corresponding polygon. So my suggestion would be, to mark all created POIs with an extra tag, e.g. mkgmap_created=add-pois-to-areas or something like that. Then I could use in the points-style a rule like type=xyz mkgmap_created!=add-pois-to-areas ... which would only place a symbol in the map if there is no corresponding polygon. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Increase MAXHINCR or MAX_HEAP_SECTS
How much memory does your system have? If the systems starts to swap mkgmap will need multitudes of time it would need normally. The error message Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS. sounds like overall memory problems. Please try to reduce the -Xmx3000M. If you don't use more than 1 thread at least -Xmx1000M should work. WanMil On 02/02/2011 09:07 PM, Bernhard Kuemel wrote: Hi! compiling http://downloads.cloudmade.com/europe/austria/austria.osm.bz2 failed: 'java -Xmx3000M -jar /usr/share/mkgmap/mkgmap.jar --route austria.osm' failed with Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS. How can I increase that? Will it help? debians dpkg says its version 0.0.0+svn1067-1. I haven't tried the current version because that hasn't finished a smaller map after 15 mins while debians mkgmap finished in seconds. Same with version 1804 after 169 minutes. There were also many of these messages: SEVERE (RoadNetwork): austria.osm: Road (http://www.openstreetmap.org/browse/way/28311585) contains zero length arc at http://www.openstreetmap.org/?mlat=mlon=zoom=17 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Increase MAXHINCR or MAX_HEAP_SECTS
I think the problem could be the cloudmade extracts. At least 2 years ago they would not work. Try with geofabrik extracts instead. (and austria without splitting into at least 7-8 tiles will not work anyhow). On 03.02.2011 19:57, WanMil wrote: How much memory does your system have? If the systems starts to swap mkgmap will need multitudes of time it would need normally. The error message Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS. sounds like overall memory problems. Please try to reduce the -Xmx3000M. If you don't use more than 1 thread at least -Xmx1000M should work. WanMil On 02/02/2011 09:07 PM, Bernhard Kuemel wrote: Hi! compiling http://downloads.cloudmade.com/europe/austria/austria.osm.bz2 failed: 'java -Xmx3000M -jar /usr/share/mkgmap/mkgmap.jar --route austria.osm' failed with Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS. How can I increase that? Will it help? debians dpkg says its version 0.0.0+svn1067-1. I haven't tried the current version because that hasn't finished a smaller map after 15 mins while debians mkgmap finished in seconds. Same with version 1804 after 169 minutes. There were also many of these messages: SEVERE (RoadNetwork): austria.osm: Road (http://www.openstreetmap.org/browse/way/28311585) contains zero length arc at http://www.openstreetmap.org/?mlat=mlon=zoom=17 ___ 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] mkgmap index rev. 1809
On 02/02/11 19:04, WanMil wrote: My results with the latest rev. 1820: Compiled Germany geofabrik extract. Mapsource: - All searches work except street search when entering a city name (the selected street is not valid in this map product. Please select a different street.). Even when the city is correct for the street name? Yes. First I search for a street name without city. Then I enter one of the city names displayed in the search results and perform the search againg. Then the given message appears. For me it is fine as long as the street/city combination exists. When it doesn't exit I see different behaviour on different installations. On one it just shows not found in the result area and on the other it has the 'Please select a different...' popup. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Am 03.02.2011 12:51, schrieb Ben Konrath: On Tue, Feb 1, 2011 at 4:20 PM, Torsten Leistikowde_m...@gmx.de wrote: Moin, Henning Scholland schrieb am 31.01.2011 21:41: Why you would like to have a POI for an object taged as node and not for a similar POI taged as polygon? In OSM some objets can be mapped in OSM as a node or as an area, depending on the availability of the source data. If they are mapped as a node, I want them to be displayed as a symbol in my map. If they are mapped as an area, I want them to be displayed as a polygon. With the pois-to-area function the latter ones are displayed in a map twice, as a polygon AND as a symbol. That's a bug. If I recall correctly, the POI should only be added if there's no POI with the same name already in the polygon. I should really fix this. Thanks for pointing it out No, this is a error in osm-data. One object should only taged once. So if you tag this information to a node, you shouldn't tag same info to the polygon. If add-pois-to-area creates an POI, there shouldn't be any node in OSM-data. If there is already a node and so there are two symbols in the map, it's not an mkgmap-bug. Henning I think Ben is right. The POI should only be added if there is no point (POI) with the same name (and the same type?) in the polygon. This is what the MapMaker.makeAreaPOIs method does if we believe what the source code comments tell us. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
On Thu, Feb 03, 2011 at 05:02:43PM +0100, Torsten Leistikow wrote: For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. For some minor map features, I would want only the symbol, not the polygon. For example, mappers could start drawing bus stop shelters from Bing aerial images. The shelters would be smaller than the Garmin map resolution, and thus the POI would be enough. So my suggestion would be, to mark all created POIs with an extra tag, e.g. mkgmap_created=add-pois-to-areas or something like that. That would scratch your itch (I would use mkgmap:generated), but it would not solve the use case that I outlined above. Obviously, add-pois-to-areas cannot consider areas that are not defined in the polygons file. Maybe if the polygons file contained a special 'no operation' rule, no polygon would be generated, but add-pois-to-areas would still generate POIs. 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] Distinguishing cycleways from footways and minor paths
Minko, On Thu, Feb 03, 2011 at 01:08:45PM +0100, Minko wrote: 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. Good that we are on the same page. How about highway=service? I suggest to display them as type 0x06. Maybe with a default_name=service? I would keep highway=service as they are (0x07), because they are usually driveways, parking aisles or alleys where the practical maxspeed is lower than on residential streets (which are 0x06). Also, some highway=service are private driveways to properties. I think that anything on 0x06 or 'bigger' road types should generally be public roads. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap index rev. 1809
1809: In Mapsource: *street search with city works*, while it did not before. send to device don't crash but fail with error Exception SourceCodeLocation SourceFileNameMDR_TRIM_ADDR.CXX/SourceFileName SourceFileLine3020/SourceFileLine /SourceCodeLocation /Exception extracted from a lot more info that I think is about the device size of _OV_mdr.img = 3724 kb 1820: In Mapsource: street search work, but street search with city broken again (try to search but finds nothing, even with correct city). send to device fails with same error but different line number SourceFileLine3020/SourceFileLine size of _OV_mdr.img = 3996 kb the same geofabrik download of Southern Africa, same MkGMap options and same Splitter options used in both cases. splitter-r161-3 used to split map into 4 tiles. java -ea -Dlog.config=Logging.txt -Xmx1000m -jar ..\Branch\mkgmap-index-r1809.jar^ --output-dir=Make%SEQ%^ --latin1^ --adjust-turn-headings^ --code-page=1252^ --country-name=South Afica^ --country-abbr=ZA^ --description=GeoAfr%DAT%^ --family-id:%SEQ%^ --family-name:GeoAfr%SEQ%^ --generate-sea:extend-sea-sectors,floodblocker^ --index^ --lower-case^ --name-tag-list:name:af,name^ --nsis^ --overview-mapname:GeoAfr%SEQ%_OV^ --product-id:%SEQ%^ --remove-short-arcs:0^ --report-similar-arcs^ --road-name-pois:0x640a^ --route^ --series-name:GeoAfrSeries%SEQ%^ --tdbfile^ --style-file:..\Styles\Bdefault^ --read-config=Template.args^ yell if you need any of the output files. BennieD This e-mail is subject to the Sappi E-Mail Legal Notice available at www.sappi.com. If you cannot access this Notice please contact the webmaster for a copy to be sent to you. Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
Am 03.02.2011 22:36, schrieb Marko Mäkelä: On Thu, Feb 03, 2011 at 05:02:43PM +0100, Torsten Leistikow wrote: For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. For some minor map features, I would want only the symbol, not the polygon. For example, mappers could start drawing bus stop shelters from Bing aerial images. The shelters would be smaller than the Garmin map resolution, and thus the POI would be enough. Did you try my hack with a transparent polygon? All in all I think the best would be an action in polygon-style for creating a POI. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Replacing --add-pois-to-areas with an add_poi action
On 04.02.2011 08:12, Henning Scholland wrote: Am 03.02.2011 22:36, schrieb Marko Mäkelä: On Thu, Feb 03, 2011 at 05:02:43PM +0100, Torsten Leistikow wrote: For some types this might be ok, but for some types I do not want the symbol in addition to the polygon. For some minor map features, I would want only the symbol, not the polygon. For example, mappers could start drawing bus stop shelters from Bing aerial images. The shelters would be smaller than the Garmin map resolution, and thus the POI would be enough. Did you try my hack with a transparent polygon? All in all I think the best would be an action in polygon-style for creating a POI. Henning I often would like to have only Polygon, but no POI. transparent is possible, but not nice, as at least on old GPS it slows them down A seperate style-file file would be best... For me the reason to use add-pois-to-areas is that I want to be able to find certain stuff via search function, but actually I would even prefer not to have a seperate POI. As that is not possible AFAIK (searching for POI that do not exist in the map but only some indexes - which is what I really would like to have) - at least not have a myriad of POI on top and a seperate file would be needed (twould probably for me cut the number of POI from polygons by 50%). ___ 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] mkgmap index rev. 1809
Hello Thanks for the results of your testing. One thing though, I see you are using the --lower-case option. Could you please try with out this option. It really shouldn't be used and is only there to show that it doesn't work! No real working map that I know of uses lower case inside the map. Thanks, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
