Re: [mkgmap-dev] Contour lines always visible
Carlos Dávila escribió:
I have successfully built contour map for Spain using srtm2osm -
splitter - mkgmap. I combine srtm img's and regular map img's with
mkgmap. Up to here everything goes fine. The problem now is that major
and medium contour lines are shown at any zoom level in MapSource and
gps, not taking into account resolution established in style (see
below). It makes rendering really slow when you zoom out and all the
map is covered by contour lines. Minor contour lines do appear at the
right zoom level (1.5 km in MapSource). The problem is in the contour
map, because it's the same if I only install it (without regular map).
Contour lines style used:
|contour=elevation contour_ext=elevation_minor
{ name '${ele|conv:m=ft}'; }
[0x20 resolution 23]
contour=elevation contour_ext=elevation_medium
{ name '${ele|conv:m=ft}'; }
[0x21 resolution 22]
contour=elevation contour_ext=elevation_major
{ name '${ele|conv:m=ft}'; }
[0x22 resolution 20]|
Commands used:
*srtm:
mono Srtm2Osm.exe -bounds1 35.99 -9.501 43.79 4.33 -step 10 -cat 100
20 -large -corrxy 0.0005 0.0005 -o srtm_peninsula.osm
*splitter:
java -Xmx2500m -jar /home/carlos/Paquetes/mkgmap/dist/splitter.jar
--mapid=63240101 --mixed=yes --cache=/160GB/cache_srtm/peninsula/
--max-nodes=500 --split-file=areas.list srtm_peninsula.osm
*regular map:
time java -Xmx600m -ea -Dlog.config=logging.properties -jar mkgmap.jar
--generate-sea=polygons,extend-sea-sectors --route --latin1
--code-page=1252 --gmapsupp --series-name=OSM-Iberia-n --index
--road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs
--add-pois-to-areas --adjust-turn-headings --report-similar-arcs
--link-pois-to-ways --location-autofill=1 --drive-on-right
--check-roundabouts --check-roundabout-flares --style=mio
--delete-tags-file=quitar_is_in -c spain.args
*contour map:
family-id=36
product-id=1
family-name=Curvas nivel Península
series-name=Curvas nivel
area-name=Península Ibérica
draw-priority=28
transparent
style=srtm
mapname: 63240101
description: SRTM-Iberia-01
input-file: /160GB/Srtm2Osm/63240101.osm.gz
mapname: 63240102
description: SRTM-Iberia-02
input-file: /160GB/Srtm2Osm/63240102.osm.gz
...
*final join:
java -ea -jar mkgmap.jar --gmapsupp --family-id=35 --product-id=1
--family-name=OSM España ../mapas/curvas-es/6324000*.img
typ/SPAIN-35.TYP --family-id=36 --product-id=1 --family-name=Curvas
nivel Península ../mapas/curvas-es/632401*.img
The problem was in the level definition in the options file. It was
levels = 0:23, 1:22, 2:20; changing it to levels = 0:23, 1:22, 2:20,
3:18 fixed the problem. In the wiki [1] its stated that the lowest
level needs to have at least one object in it, but it seems to be right
the opposite, as I needed to add an extra 3:18 level which has no object
in it to get it work. I know this page of the wiki is quite outdated
(there was no mention to styles in it), so if you can give some
information about this issue I will update it accordingly.
Now that contour lines are correctly drawn a new problem arises. If I
combine contour img's with osm img's either with mkgmap or gmaptool all
map becomes flooded. If I combine them with MapSource land is ok, but
routing is broken. So, there must be still something I'm doing wrong.
[1] http://wiki.openstreetmap.org/wiki/Mkgmap/help/custom#Level
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
Okay here are my results (actually the same as with gmaptool, I did not notice that how profile can be shown). 1.Only normal map without contourlines: Mapsource/Basecamp show profile is greyed out. 2. Only contourline map: Working in both: Mapsource 6.13.6, 6.15.11 as well as Basecamp 2.0.8 3. Mixed map made out of .img with osm mapt data and .img with contourlines (joined using: java -ea -jar -Xmx512M mkgmap.jar --index --description=%srtm% --route --country-abbr=%abr%_srtm --country-name=%date%_srtm --mapname=%FID% --family-id=%FID% --product-id=1 --series-name=%srtm% --family-name=%srtm% --tdbfile --overview-mapname=mapset --area-name=%country% 6*.img 7*.img :) Mapsource 6.13.6 on clicking on show profile empty profile comes up. Mapsource 6.15.11 clicking on show profile: crash Basecamp: Clicking on elevation profile: Message The current map does not contain any elevation data on the selected route. 4. Normal map including contourlines (contourlines as osm file merged with normal osm file using osmosis): Profile working in Mapsource/Basecamp. This is a lot of work and time. Also not legally possible with srtm data from viewfinderpanoramas.org. Is anyone able to get 3. working (without loosing autorouting)?? Does the patch have any effect on the .img (if so I would try to recompile my .img contourlines) Currently I need to seperate installs: Meaning both map as described and 2. and 3. I calculate my route on 3., then switch to contourline only map, and now clicking on show profile (only in Mapsoruce 6.15.11/Basecamp, not however in 6.13.x) a nice profile is shown. In Mapsource 6.13.6 I am not able at all to get a profile shown. (have not yet tried on GPS, but I think map as described under 3. would work for both autorouting and profile). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Confusing results when uploading.
Hello Charlie Charlie Ferrero wrote: Dave F. wrote: It's a bit tricky to understand what you're trying to do in the second compile. For instance, you're applying --remove-short-arcs to pre-built IMG files, which doesn't make much sense. I'm a bit surprised to hear you say that. I'm aware that the options are processed in the order I list them, but surely mkgmap knows what they are to be applied to. ie the .OSM file not the .IMGs that are part of the --gmapsupp option? You're also mixing pre-existing IMG files with OSM files, which I'd avoid if I were you. Better to create all the IMG files seperately, then compile them into your ultimate gmapsupp.img in one step at the end. I'm following instructions from the mkgmap wiki: *--gmapsupp* Write a gmapsupp.img file, possibly joining previous gmapsupp.img (you need to copy in the Mkgmap's working directory), that can be uploaded to a Garmin device in USB mode. java -jar mkgmap.jar --gmapsupp corsica.img cyprus.img mallorca.img malta.img tenerife.img Are you saying this is to be avoided? I appreciate your website. I've found it very useful. Cheers Dave F. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
Turn restrictions do not seem to work with mp file input. Would this be difficult to add? Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
15.02.2010 15:07:01, Garvan maew kirjoitti: Turn restrictions do not seem to work with mp file input. Would this be difficult to add? How would you represent turn restrictions in MP files? Does the MP format support relations? For what it is worth, multipolygons are implemented as relations too and thus should not work in the MP format. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Implementing turn restrictions in mp input format
Apologizes for the wrong subject in my last post, I will try again. Turn restrictions do not seem to work with mp file input. Would this be difficult to add? Garvan Garvan maew wrote: Turn restrictions do not seem to work with mp file input. Would this be difficult to add? Garvan ___ 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] Confusing results when uploading.
Dave F. (dave...@madasafish.com) wrote: Hello Charlie Charlie Ferrero wrote: Dave F. wrote: It's a bit tricky to understand what you're trying to do in the second compile. For instance, you're applying --remove-short-arcs to pre-built IMG files, which doesn't make much sense. I'm a bit surprised to hear you say that. I'm aware that the options are processed in the order I list them, but surely mkgmap knows what they are to be applied to. ie the .OSM file not the .IMGs that are part of the --gmapsupp option? You're also mixing pre-existing IMG files with OSM files, which I'd avoid if I were you. Better to create all the IMG files seperately, then compile them into your ultimate gmapsupp.img in one step at the end. I'm following instructions from the mkgmap wiki: *--gmapsupp* Write a gmapsupp.img file, possibly joining previous gmapsupp.img (you need to copy in the Mkgmap's working directory), that can be uploaded to a Garmin device in USB mode. java -jar mkgmap.jar --gmapsupp corsica.img cyprus.img mallorca.img malta.img tenerife.img Are you saying this is to be avoided? The wiki only describes combining IMG files together, whereas you appear to be both combining IMG files whilst also processing OSM files, in the same step. Like I said before, I'd recommend you do all the OSM processing first. Then combine IMG files in a second, separate step. I'm not saying that you can't do it any other way, just that this way works! -- Charlie ___ 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
Hi WanMil, 2nd: the multipolygon code should not remove the boundary tags from the singular ways. Additionally the polygons created by the multipolygon code could be tagged with mkgmap:mp_boundary=yes. This tag could be evaluated in the style definition so the style could differ between the polygons created by the mp code and the lines not touched by mp code. This sounds sensible to me. The style could have an additional rule that filters out generated lines. I would set the attribute on all MultiPolygon-generated lines, not just on boundaries. (Someone could want to draw coastlines as lines on a separate map layer, for example, and the generated lines would interfere.) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
Hello Garvan, Turn restrictions do not seem to work with mp file input. Would this be difficult to add? I am not familiar with the way the turn restrictions are specified in MP files but I doubt if it is difficult to add support for them. Personally, I would prefer to spend my (limited) time working on OSM related features or making the core functionality better so I am not keen to work on that. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Implementing turn restrictions in mp input format
Marko Mäkelä wrote: 15.02.2010 15:07:01, Garvan maew kirjoitti: Turn restrictions do not seem to work with mp file input. Would this be difficult to add? How would you represent turn restrictions in MP files? Does the MP format support relations? For what it is worth, multipolygons are implemented as relations too and thus should not work in the MP format. Marko Turn restrictions are implemented like this [Restrict] Nod=29298 TraffPoints=29431,29298,29431 TraffRoads=4791,4791 Time= [END-Restrict] [Restrict] Nod=29298 TraffPoints=29324,29298,29324 TraffRoads=4756,4756 Time= [END-Restrict] [Restrict] Nod=29298 TraffPoints=29303,29298,29303 TraffRoads=4756,4756 Time= [END-Restrict] This is a No U-Turns on all roads at a T junction as emitted by gpsmapedit. Nod=29298 is the actual point at the junction. I could make many more examples in gpsmapedit until I had a full understanding of the syntax. The mp file format supports the old definition of multipoligons where you have one outer and many inners, but the inner polygons must be in reverse direction (anti-clockwise) to show they are holes. Thus it covers all the basics as far a geometry is concerned, so tagging remains the only issue. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with validity times
Turn restrictions are implemented like this [Restrict] Nod=29298 TraffPoints=29431,29298,29431 TraffRoads=4791,4791 Time= [END-Restrict] What I find interesting in this excerpt: It has a definition for time. I expect here the validity times for this restrictions. This would mean, that the garmin img format can handle this. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
Mark Burton wrote: Hello Garvan, Turn restrictions do not seem to work with mp file input. Would this be difficult to add? I am not familiar with the way the turn restrictions are specified in MP files but I doubt if it is difficult to add support for them. Personally, I would prefer to spend my (limited) time working on OSM related features or making the core functionality better so I am not keen to work on that. Cheers, I understand that everybody must set their own priorities on how they use their available free time. I hope there might be others that could help with keeping the mp input up-to-date. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with validity times
Hello Johann, It has a definition for time. I expect here the validity times for this restrictions. This would mean, that the garmin img format can handle this. Sure it can - Garmin turn restrictions can be a lot more complicated than we know how to encode. If you want to learn more about turn restriction encoding, take a look at the source for gpsmapedit. Mark Thats interesting. I thought always gpsmapedit relays on cGPSmapper to parse the garmin img format. I personally dont use this tool, (no windows available) so I dont know it. Also I'm astonished, that there is source code available. Reading the license site it says: 2.2 Reverse Engineering. You may not modify, reverse engineer, decompile, disassemble (except to the extent applicable laws specifically prohibit such restrictions) or create derivative works based on the Software, or any portion thereof. But on the other hand: 2.8 Source Code. You may evaluate the Source Code freely while the right to use and modify the Source Code for development of own products is granted only if (a) the registration fee for the Software is paid; (b) it is prohibited to remove original copyright notes in the source files; (c) you may use Source Code in own programs, provided that the copyright notes of the programs should include the reference to the Author (portions Konstantin Galichsky, k...@geopainting.com) and to the Software Web page (http://www.geopainting.com;). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Turn restrictions with validity times
2.2 Reverse Engineering. You may not modify, reverse engineer, decompile, disassemble (except to the extent applicable laws specifically prohibit such restrictions) or create derivative works based on the Software, or any portion thereof. But on the other hand: 2.8 Source Code. You may evaluate the Source Code freely while the right to use and modify the Source Code for development of own products is granted only if (a) the registration fee for the Software is paid; (b) it is prohibited to remove original copyright notes in the source files; (c) you may use Source Code in own programs, provided that the copyright notes of the programs should include the reference to the Author (portions Konstantin Galichsky, k...@geopainting.com) and to the Software Web page (http://www.geopainting.com;). Well a large part of gpsmapedit is not open sourced, therefore 2.2 and 2.8 differences. That's at least how I understand it. ___ 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] Name sequence
On 12/02/10 18:18, Chris-Hein Lunkhusen wrote: I created a test map of Tokyo and want to use the name:en tag for the names. But I found that changing the name_tag = name:en in the options file is not working. The option is name-tag-list and not name_tag, if that wasn't just a typo. I had forgotten how it worked somewhat, but looking at the code it should work in the way you want: the name tag is replaced by the first matching tag in the list that exists before processing the way. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Name sequence
On 12/02/10 18:18, Chris-Hein Lunkhusen wrote: I created a test map of Tokyo and want to use the name:en tag for the names. But I found that changing the name_tag = name:en in the options file is not working. The option is name-tag-list and not name_tag, if that wasn't just a typo. I had forgotten how it worked somewhat, but looking at the code it should work in the way you want: the name tag is replaced by the first matching tag in the list that exists before processing the way. ..Steve The default style gives an example with name_tag. So this should be corrected. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Name sequence
The default style gives an example with name_tag. So this should be corrected. So it does :( That must have been from when you could just give one name and not a list. I'll change it now. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1572: Correct and expand documentation of name-tag-list
Version 1572 was commited by steve on 2010-02-15 16:29:04 + (Mon, 15 Feb 2010) Correct and expand documentation of name-tag-list ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dent in street and bounds problem
Felix Hartmann schrieb am 14.02.2010 21:10: That is a bug in Mapsource and won't get solved. Use Mapsource 6.13.6 (for x64 systems) or Mapsource 6.13.7 for x32 system. This might help, I am using a 6.11 version of Mapsource. Unfortunately my Nuevi displays it in the same way Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dent in street and bounds problem
Mark Burton schrieb am 14.02.2010 23:15: How about: the RHS of the dent is S of the junction with Bruchweg because the small footway has been completely removed by the remove-short-arcs option and so the node at the N end of that footway has been merged into the node at the S end of the footway which is why the way ends up kinked to the S. I haven't noticed this, but your right: The footway is misisng in the garmin map. But is this not a much bigger problem? Now in the Garmin map two roads are connected, which are not connected in the OSM data. I think the remove-short-arcs option mustn't remove complete elements, because the routing is now broken. And such a case is not so exceptional: Here it is quite common, that an end of a road is closed for vehicle traffic or declared as oneway for reducing the traffic in residential areas. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dent in street and bounds problem
Hello Torsten, Mark Burton schrieb am 14.02.2010 23:15: How about: the RHS of the dent is S of the junction with Bruchweg because the small footway has been completely removed by the remove-short-arcs option and so the node at the N end of that footway has been merged into the node at the S end of the footway which is why the way ends up kinked to the S. I haven't noticed this, but your right: The footway is misisng in the garmin map. But is this not a much bigger problem? Now in the Garmin map two roads are connected, which are not connected in the OSM data. I think the remove-short-arcs option mustn't remove complete elements, because the routing is now broken. And such a case is not so exceptional: Here it is quite common, that an end of a road is closed for vehicle traffic or declared as oneway for reducing the traffic in residential areas. Yes, that's not ideal is it. I will add it to the list of bugs that I need to fix. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] Multipolygon code enabled for overlapping lines
Hi WanMil, I downloaded the finland OSM dump from geofabrik from today (Feb 15th). I used splitter v105 and the areas.list file from http://www.polkupyoraily.net/osm/ to get three tiles. Then I tried that patch: * I got no warning for mp 404644 * I got only one unknown reason warning for complete finland What did you see above the unknown reason warning? I saw this when using yesterday’s dump and your patch applied on top of mkgmap r1569 (IIRC): 2010/02/14 21:52:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/404644 contains errors. 2010/02/14 21:52:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon 4611686018427397822(178P : (23045442[43P],19548137[36P],19560742[66P],25581658[35P]) is not processed due to an unknown reason. With today’s dump and mkgmap r1571, I see no such warning. I did not see a warning either with yesterday’s dump and r1569 (IIRC). Apart from improving handling on the tile boundaries (which will be another main patch) I don't see anything to improve. Did you really use the patch? I think I did. I just retried mp_linesoverlapping_v4.patch with today’s dump, and sure enough, I do see the 'unknown reason' warning that I thought was for relation 404644: 2010/02/15 21:41:07 WARNING (MultiPolygonRelation): 63240001.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/404644 2010/02/15 21:41:07 WARNING (MultiPolygonRelation): 63240001.osm.gz: - way: http://www.openstreetmap.org/browse/way/25581758 2010/02/15 21:41:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/404644 contains errors. 2010/02/15 21:41:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon 4611686018427397822(178P : (23045442[43P],19548137[36P],19560742[66P],25581658[35P]) is not processed due to an unknown reason. 2010/02/15 09:59:56 WARNING (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/404644 does not contain any way tagged with role=outer. OK, without the patch, I see one warnings for 404644 in 63240001.osm.gz and two in 63240002.osm.gz, most likely due to incorrect splitting. Here is the warning for 63240001.osm.gz: 2010/02/15 09:59:12 WARNING (MultiPolygonRelation): 63240001.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/404644 2010/02/15 09:59:12 WARNING (MultiPolygonRelation): 63240001.osm.gz: - way: http://www.openstreetmap.org/browse/way/25581758 Can you figure out what is behind the 'unknown reason' if it is not the incorrectly split relation 404644? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
Am 15.02.2010 12:02, schrieb Felix Hartmann: Okay here are my results (actually the same as with gmaptool, I did not notice that how profile can be shown). 1.Only normal map without contourlines: Mapsource/Basecamp show profile is greyed out. 2. Only contourline map: Working in both: Mapsource 6.13.6, 6.15.11 as well as Basecamp 2.0.8 3. Mixed map made out of .img with osm mapt data and .img with contourlines (joined using: java -ea -jar -Xmx512M mkgmap.jar --index --description=%srtm% --route --country-abbr=%abr%_srtm --country-name=%date%_srtm --mapname=%FID% --family-id=%FID% --product-id=1 --series-name=%srtm% --family-name=%srtm% --tdbfile --overview-mapname=mapset --area-name=%country% 6*.img 7*.img :) Mapsource 6.13.6 on clicking on show profile empty profile comes up. Mapsource 6.15.11 clicking on show profile: crash Basecamp: Clicking on elevation profile: Message The current map does not contain any elevation data on the selected route. 4. Normal map including contourlines (contourlines as osm file merged with normal osm file using osmosis): Profile working in Mapsource/Basecamp. This is a lot of work and time. Also not legally possible with srtm data from viewfinderpanoramas.org. Is anyone able to get 3. working (without loosing autorouting)?? Does the patch have any effect on the .img (if so I would try to recompile my .img contourlines) Currently I need to seperate installs: Meaning both map as described and 2. and 3. I calculate my route on 3., then switch to contourline only map, and now clicking on show profile (only in Mapsoruce 6.15.11/Basecamp, not however in 6.13.x) a nice profile is shown. In Mapsource 6.13.6 I am not able at all to get a profile shown. (have not yet tried on GPS, but I think map as described under 3. would work for both autorouting and profile). There is no change to the img files. I tryed scenario 3. and got the same problems. I think MapSource gets confused having two img's for the same area. Knowing this scenaro its required to have an option to turn it off. Until now I created my maps as described in 4. But using a fix areas.list from splitter so I had not to rebuild contour lines osm again and again. Actually I am working on the integrated contour line feature of mkgmap. It failed if a map didn't fit in a single DEM data file (SRTM, CGIAR or ASTER). For SRTM data I am now able to cover larger areas. The time went up from around 1.5 hours for my germany generation to 2 hours not counting the time previously required to generate and merge elevation osm with srtm2osm and osmosis. So this approach seems to be not slower and saves disk space. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
On 15.02.2010 21:30, Ronny Klier wrote: Am 15.02.2010 12:02, schrieb Felix Hartmann: Okay here are my results (actually the same as with gmaptool, I did not notice that how profile can be shown). 1.Only normal map without contourlines: Mapsource/Basecamp show profile is greyed out. 2. Only contourline map: Working in both: Mapsource 6.13.6, 6.15.11 as well as Basecamp 2.0.8 3. Mixed map made out of .img with osm mapt data and .img with contourlines (joined using: java -ea -jar -Xmx512M mkgmap.jar --index --description=%srtm% --route --country-abbr=%abr%_srtm --country-name=%date%_srtm --mapname=%FID% --family-id=%FID% --product-id=1 --series-name=%srtm% --family-name=%srtm% --tdbfile --overview-mapname=mapset --area-name=%country% 6*.img 7*.img :) Mapsource 6.13.6 on clicking on show profile empty profile comes up. Mapsource 6.15.11 clicking on show profile: crash Basecamp: Clicking on elevation profile: Message The current map does not contain any elevation data on the selected route. 4. Normal map including contourlines (contourlines as osm file merged with normal osm file using osmosis): Profile working in Mapsource/Basecamp. This is a lot of work and time. Also not legally possible with srtm data from viewfinderpanoramas.org. Is anyone able to get 3. working (without loosing autorouting)?? Does the patch have any effect on the .img (if so I would try to recompile my .img contourlines) Currently I need to seperate installs: Meaning both map as described and 2. and 3. I calculate my route on 3., then switch to contourline only map, and now clicking on show profile (only in Mapsoruce 6.15.11/Basecamp, not however in 6.13.x) a nice profile is shown. In Mapsource 6.13.6 I am not able at all to get a profile shown. (have not yet tried on GPS, but I think map as described under 3. would work for both autorouting and profile). There is no change to the img files. I tryed scenario 3. and got the same problems. I think MapSource gets confused having two img's for the same area. Knowing this scenaro its required to have an option to turn it off. Until now I created my maps as described in 4. But using a fix areas.list from splitter so I had not to rebuild contour lines osm again and again. Actually I am working on the integrated contour line feature of mkgmap. It failed if a map didn't fit in a single DEM data file (SRTM, CGIAR or ASTER). For SRTM data I am now able to cover larger areas. The time went up from around 1.5 hours for my germany generation to 2 hours not counting the time previously required to generate and merge elevation osm with srtm2osm and osmosis. So this approach seems to be not slower and saves disk space. Well if it were possible the best way to use it would be If mkgmap could do the merging. Of course it is clear that one has to cut down on the max-nodes a bit more, but except the Alps excerpt from Geofabrik, all regions are pretty easy. There would be several ways that I would think of as very successful: a) mkgmap accepts osm AND .img as input, and simply takes the contourlines from the .img and adds them to the tiles after the normal osm data has been written. This would of course require support for reading in .img files (but I think it should not be to much work to implement if one limits this to plain lines without routing, indexes and so on read in. b) Compiling to img from mp for Contourlines my PC needs 8 minutes for all of Europe (Germany is 35seconds). So for a) simply exchange .img input by mp input. c) make mkgmap combine .img files. That would be the nicest solution. d) make mkgmap able to write out 2 osm files into one single .img. That should be the easiest solution. Above scenario 3 has the added problem that sometimes the contourlines do show up in Mapsource, sometimes not. Reopening/Closing Mapsource changes the situation. I don't know how to get contourline .img shown permanently on top of the other maps (simply using higher ID does NOT work, even more strange if I feed mkgmap with java mkgmap.jar 6*.img 7*.img with 7*.img being the contourlines it sometimes works, If I change the command around to java mkgmap.jar 7*.img 6*.img the contourlines are never on top in Mapsource; the only thing that seems to work always is to run java mkgmap .jar . *.osm *.mp) ___ 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] [PATCH v4] Multipolygon code enabled for overlapping lines
Hi WanMil, I downloaded the finland OSM dump from geofabrik from today (Feb 15th). I used splitter v105 and the areas.list file from http://www.polkupyoraily.net/osm/ to get three tiles. Then I tried that patch: * I got no warning for mp 404644 * I got only one unknown reason warning for complete finland What did you see above the unknown reason warning? I saw this when using yesterday’s dump and your patch applied on top of mkgmap r1569 (IIRC): 2010/02/14 21:52:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/404644 contains errors. 2010/02/14 21:52:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon 4611686018427397822(178P : (23045442[43P],19548137[36P],19560742[66P],25581658[35P]) is not processed due to an unknown reason. With today’s dump and mkgmap r1571, I see no such warning. I did not see a warning either with yesterday’s dump and r1569 (IIRC). Apart from improving handling on the tile boundaries (which will be another main patch) I don't see anything to improve. Did you really use the patch? I think I did. I just retried mp_linesoverlapping_v4.patch with today’s dump, and sure enough, I do see the 'unknown reason' warning that I thought was for relation 404644: 2010/02/15 21:41:07 WARNING (MultiPolygonRelation): 63240001.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/404644 2010/02/15 21:41:07 WARNING (MultiPolygonRelation): 63240001.osm.gz: - way: http://www.openstreetmap.org/browse/way/25581758 2010/02/15 21:41:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/404644 contains errors. 2010/02/15 21:41:08 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon 4611686018427397822(178P : (23045442[43P],19548137[36P],19560742[66P],25581658[35P]) is not processed due to an unknown reason. 2010/02/15 09:59:56 WARNING (MultiPolygonRelation): 63240002.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/404644 does not contain any way tagged with role=outer. OK, without the patch, I see one warnings for 404644 in 63240001.osm.gz and two in 63240002.osm.gz, most likely due to incorrect splitting. Here is the warning for 63240001.osm.gz: 2010/02/15 09:59:12 WARNING (MultiPolygonRelation): 63240001.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/404644 2010/02/15 09:59:12 WARNING (MultiPolygonRelation): 63240001.osm.gz: - way: http://www.openstreetmap.org/browse/way/25581758 Can you figure out what is behind the 'unknown reason' if it is not the incorrectly split relation 404644? Marko Marko, if you want to know exactly what's happening please start mkgmap with debug-level FINE. I don't do anything else. I am happy for any good hint what might be a problem. But I don't investigate every warning of the mp code. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Enable elevation profile in MapSource
Am 15.02.2010 22:13, schrieb Felix Hartmann: On 15.02.2010 21:30, Ronny Klier wrote: Am 15.02.2010 12:02, schrieb Felix Hartmann: Okay here are my results (actually the same as with gmaptool, I did not notice that how profile can be shown). 1.Only normal map without contourlines: Mapsource/Basecamp show profile is greyed out. 2. Only contourline map: Working in both: Mapsource 6.13.6, 6.15.11 as well as Basecamp 2.0.8 3. Mixed map made out of .img with osm mapt data and .img with contourlines (joined using: java -ea -jar -Xmx512M mkgmap.jar --index --description=%srtm% --route --country-abbr=%abr%_srtm --country-name=%date%_srtm --mapname=%FID% --family-id=%FID% --product-id=1 --series-name=%srtm% --family-name=%srtm% --tdbfile --overview-mapname=mapset --area-name=%country% 6*.img 7*.img :) Mapsource 6.13.6 on clicking on show profile empty profile comes up. Mapsource 6.15.11 clicking on show profile: crash Basecamp: Clicking on elevation profile: Message The current map does not contain any elevation data on the selected route. 4. Normal map including contourlines (contourlines as osm file merged with normal osm file using osmosis): Profile working in Mapsource/Basecamp. This is a lot of work and time. Also not legally possible with srtm data from viewfinderpanoramas.org. Is anyone able to get 3. working (without loosing autorouting)?? Does the patch have any effect on the .img (if so I would try to recompile my .img contourlines) Currently I need to seperate installs: Meaning both map as described and 2. and 3. I calculate my route on 3., then switch to contourline only map, and now clicking on show profile (only in Mapsoruce 6.15.11/Basecamp, not however in 6.13.x) a nice profile is shown. In Mapsource 6.13.6 I am not able at all to get a profile shown. (have not yet tried on GPS, but I think map as described under 3. would work for both autorouting and profile). There is no change to the img files. I tryed scenario 3. and got the same problems. I think MapSource gets confused having two img's for the same area. Knowing this scenaro its required to have an option to turn it off. Until now I created my maps as described in 4. But using a fix areas.list from splitter so I had not to rebuild contour lines osm again and again. Actually I am working on the integrated contour line feature of mkgmap. It failed if a map didn't fit in a single DEM data file (SRTM, CGIAR or ASTER). For SRTM data I am now able to cover larger areas. The time went up from around 1.5 hours for my germany generation to 2 hours not counting the time previously required to generate and merge elevation osm with srtm2osm and osmosis. So this approach seems to be not slower and saves disk space. Well if it were possible the best way to use it would be If mkgmap could do the merging. Of course it is clear that one has to cut down on the max-nodes a bit more, but except the Alps excerpt from Geofabrik, all regions are pretty easy. There would be several ways that I would think of as very successful: a) mkgmap accepts osm AND .img as input, and simply takes the contourlines from the .img and adds them to the tiles after the normal osm data has been written. This would of course require support for reading in .img files (but I think it should not be to much work to implement if one limits this to plain lines without routing, indexes and so on read in. b) Compiling to img from mp for Contourlines my PC needs 8 minutes for all of Europe (Germany is 35seconds). So for a) simply exchange .img input by mp input. c) make mkgmap combine .img files. That would be the nicest solution. d) make mkgmap able to write out 2 osm files into one single .img. That should be the easiest solution. Above scenario 3 has the added problem that sometimes the contourlines do show up in Mapsource, sometimes not. Reopening/Closing Mapsource changes the situation. I don't know how to get contourline .img shown permanently on top of the other maps (simply using higher ID does NOT work, even more strange if I feed mkgmap with java mkgmap.jar 6*.img 7*.img with 7*.img being the contourlines it sometimes works, If I change the command around to java mkgmap.jar 7*.img 6*.img the contourlines are never on top in Mapsource; the only thing that seems to work always is to run java mkgmap .jar . *.osm *.mp) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev These ways would be great still they are not related to what the contour lines part of mkgmap does ;-) I am with you: d) should be the simplest to implement (Not knowing whats really neccessary for this to work). I think everything which involves reading img files is a lot harder because the file structure seems not to be straight forward readable. ___
[mkgmap-dev] [PATCH v2] Enable elevation profile in MapSource
v2 adds new option show-profiles to enable or disable this feature.
Default is disabled.
Original-Nachricht
Betreff: [PATCH] Enable elevation profile in MapSource
Datum: Sun, 14 Feb 2010 23:53:31 +0100
Von: Ronny Klier ronny.kl...@s1999.tu-chemnitz.de
Antwort an: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk
An: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk
Newsgruppen: gmane.comp.gis.openstreetmap.mkgmap.devel
Hi,
there seems to be a way to show elevation profiles for a route without
having the DEM subfiles stored in the map.
There is a byte in TDB file's header section which can be set to 1. If
set MapSource generates the profile from the contour lines. The result
is not as good as having the full information from DEM subfiles but
better than nothing.
Please try this patch, especially with maps without contour lines. Maybe
setting this flag has to be bound to existing contour lines.
Ronny
Index: resources/help/en/options
===
--- resources/help/en/options (revision 1569)
+++ resources/help/en/options (working copy)
@@ -370,6 +370,11 @@
--tdbfile
Write a .tdb file.
+--show-profiles=1
+ Sets a flag in tdb file which marks set mapset as having contour
+ lines and allows showing profile in MapSource. Default is 0
+ which means disabled.
+
--draw-priority=25
When two maps cover the same area, this option controls what
order they are drawn in and therefore which map is on top of
Index: src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java
===
--- src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java (revision 1569)
+++ src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java (working copy)
@@ -84,10 +84,17 @@
} else {
tdbVersion = TdbFile.TDB_V407;
}
+ // enable show profile button for routes in mapsource
+ byte enableProfile = 0;
+ if (tdbVersion == TdbFile.TDB_V407)
+ {
+ // this is supported only in version 403 and above
+ enableProfile = (byte)args.get(show-profiles, 0);
+ }
tdb = new TdbFile(tdbVersion);
tdb.setProductInfo(familyId, productId, productVersion,
seriesName,
- familyName, areaName);
+ familyName, areaName, enableProfile);
}
/**
Index: src/uk/me/parabola/tdbfmt/HeaderBlock.java
===
--- src/uk/me/parabola/tdbfmt/HeaderBlock.java (revision 1569)
+++ src/uk/me/parabola/tdbfmt/HeaderBlock.java (working copy)
@@ -49,6 +49,8 @@
*/
private String familyName;
+ private byte enableProfile;
+
HeaderBlock(int tdbVersion) {
this.tdbVersion = tdbVersion;
}
@@ -92,8 +94,12 @@
os.write3(0);
os.write4(1252);
os.write4(1);
- os.write(1);
- os.write2(0);
+ os.write(1);// map is routable
+ if (enableProfile == 1)
+ os.write(1);// map has profile information
+ else
+ os.write(0);
+ os.write(0);// map has DEM sub files
}
}
@@ -154,4 +160,8 @@
public int getTdbVersion() {
return tdbVersion;
}
+
+ public void setEnableProfile(byte enableProfile) {
+ this.enableProfile = enableProfile;
+ }
}
Index: src/uk/me/parabola/tdbfmt/TdbFile.java
===
--- src/uk/me/parabola/tdbfmt/TdbFile.java (revision 1569)
+++ src/uk/me/parabola/tdbfmt/TdbFile.java (working copy)
@@ -92,7 +92,8 @@
}
public void setProductInfo(int familyId, int productId,
- short productVersion, String seriesName, String
familyName, String overviewDescription)
+ short productVersion, String seriesName, String
familyName, String overviewDescription,
+ byte enableProfile)
{
headerBlock = new HeaderBlock(tdbVersion);
headerBlock.setFamilyId((short) familyId);
@@ -100,6 +101,7 @@
headerBlock.setProductVersion(productVersion);
headerBlock.setSeriesName(seriesName);
headerBlock.setFamilyName(familyName);
+ headerBlock.setEnableProfile(enableProfile);
this.overviewDescription = overviewDescription;
}
___
mkgmap-dev mailing list
[mkgmap-dev] TYP files : an new tool
Hello there, I know some of you are looking for a tool which could produce TYP file. I was on the same way since last december. This may help you... http://emerald-island.eu/wikka/MakeTyp Written in C++, the tool is based on this great Perl script from http://ati.land.cz/ and use FreeImage for cool images transformations This is my first release, use it carefully. Cheers, David PS : now, it is your turn, make a graphical editor. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] typ file not included with generating gmapsupp
My typ file is not incluced when I created a gpamsupp file from a previous mkgmap run time java -Xmx1512m -jar mkgmap.jar --read-config=args.list philippines.osm time java -Xmx1512m -jar mkgmap.jar --gmapsupp some_dir/*.img some_dir/MINIMAL.TYP -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] typ file not included with generating gmapsupp
I'm using mkgmap ver 1564 On Tue, Feb 16, 2010 at 12:11 PM, maning sambale emmanuel.samb...@gmail.com wrote: My typ file is not incluced when I created a gpamsupp file from a previous mkgmap run time java -Xmx1512m -jar mkgmap.jar --read-config=args.list philippines.osm time java -Xmx1512m -jar mkgmap.jar --gmapsupp some_dir/*.img some_dir/MINIMAL.TYP -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
