[mkgmap-dev] Bugfix: the tag mkgmap:gtype didn't set the road speed properly.
In the code handling the mkgmap:gtype tag the road class is set twice, but it
should be the road speed the second time. See the attached patch to correct
this.
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1643)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -264,7 +264,7 @@
if(vals.length = 6 vals[5].length() 0) {
try {
- gt.setRoadClass(Integer.decode(vals[5]));
+ gt.setRoadSpeed(Integer.decode(vals[5]));
}
catch (NumberFormatException nfe) {
log.error(OSM element + element.getId() +
has bad value for roadspeed: + vals[5]);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Do not write unnecessary POI information
Some stats about the patch: With my map (OSM Radkarte) the difference in size of the gmapsupp.img is 626622464 bytes (with patch) to 638369792 bytes (w/o patch), that is a reduction in size of about 1.8 %. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Do not write unnecessary POI information
Am 19.04.2010 um 22:32 schrieb Charlie Ferrero: My tests suggest that only POIs in the range 0x2A00 to 0x32FF can carry address information. Hi Charlie, could you elaborate on that? What tests did you do and with what kind of GPS/software? My experience with the Garmin stuff is that this needn't be the same over the whole model range... Anyway, I've attached a patch with your range. This one should actually do what it is supposed to do. What I found out while looking at the source is, that while country and region strings are only saved once and then shared between all entries, the POI entries itself are not shared, even if they are identical. From looking at the file format it should be possible to share the entries. This should save a lot of space if you have a default name for a lot of your POIs that don't have/display address info. Regards Thilo reduce_unnecessary_poi_infos.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - Do not write unnecessary POI information
The attached patch will prevent writing the additional POI information (address, phone number) if - it won't be shown (POIs with IDs 0x64xx to 0x66xx won't have their information shown) - there is no street given for that POI reduce_unnecessary_poi_infos.patch Description: Binary data This reduces the size of the map by about 5% for my map (with a lot of POIs actually generated in the range 0x64xx to 0x66xx). It may be questionable to write no address information if there is no street given. IMHO though, what I want to have from that additional information is the street address. I can see on the map in which city and region the POI is in and in most cases I can also see the distance to my current location. So if I don't have at least a street name the information about the city and region alone (which is most likely autogenerated and therefore error-prone anyway) doesn't help. For my maps the additional size reduction of this is less than 1 % (which I don't understand BTW, should be more). I'm not sure about the ID range 0x64xx to 0x66xx - has anybody tested this and knows whether there are additional IDs that won't have their information shown? Regards Thilo___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - Do not write unnecessary POI information
Am 18.04.2010 um 19:15 schrieb Felix Hartmann: On 18.04.2010 10:46, Thilo Hannemann wrote: I'm not sure about the ID range 0x64xx to 0x66xx - has anybody tested this and knows whether there are additional IDs that won't have their information shown? Regards Thilo Actually it is much more. 0x4100 and bigger show no contact Information (this of course also includes all 0x1 ) - Or has someone found any POI above 0x4099 show any kind of contact information I've changed it so that now there is no contact information for 0x1Cxx and for everything starting from 0x4100. I've found somewhere on the internet that POIs with 0x1Cxx don't have their contact information shown. We would also need to exclude all cities (0x0*) to 0x1199 do not show any contact information (I'm not sure whether 0x13?? to ox1f?? do show contact information - as I never used any POI inside this range). I don't know how to adapt your patch to ONLY put contact information for 0x1300 - 0x4099 - but that is what we essentially need (maybe it is even 0x2000 - 0x4099). Plus we need to exclude 0x0 (e.g. 0x01709) Cities are already excluded. They are handled separately and don't get any contact information. As a second patch I think we would really need an option to switch of the fix my address nonsense. It only takes up space. So either replace that text by a simple dot . or get rid of adding contact info alltogether if there is no address/or other info we want to put once we have several keys that are added! My patch gets rid of it, because it will only create the contact information if a street is given. That part of the code won't be executed anymore, so I removed it in v2. reduce_unnecessary_poi_infos.patch Description: Binary data Regards Thilo___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - Do not write unnecessary POI information
When looking at the code I'm not so sure anymore that this patch does what I expect it to do. So please do *not* include it into trunk. I'll think about it and will come up with another one. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS Problems with 2G limit
Am 08.04.2010 um 12:48 schrieb Christoph Wagner: I am not a windows hacker and have no knowledge about the nsis system. Maybe we could add some params to the --nsis option of mkgmap like: --nsis=nodata or something to avoid including the files in the exe directly. In principle you could do that. But you don't need that option, because if the installation data is not included in the installer you could build it once and change only the data. The user has to download several files though and you will need some error checking to see that all needed files are present and that they are from the same map (especially for updates). IMHO the nice thing about NSIS is that the users needs only one file for download. Another approach would be to split your map of Europe into several parts, say northern Europe and southern Europe. If you run the splitter on the whole of Europe and select the tiles that go into each part for mkgmap, the parts should fit perfectly and routing should work as well. This will also reduce the download volume for users that are interested only in some part of Europe. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS Problems with 2G limit
Hi Christoph, you'll find the answer here: http://nsis.sourceforge.net/I_get_an_error_when_compiling_large_installers There seems to be a limit in the archive format of the installer so that the compressed data may not be larger than 2 GB. The recommendation is to use a multi-volume install instead - that is to split the data into several files. Using plug-ins the installer can read those additional files and install them together with its regular payload. As this is quite often discussed there seems to be no other workaround. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Shuttle-Train
Attached is a patch that allows you to build routable ways from relations.
generate_ways_from_relations.patch
Description: Binary data
You use it by adding a [ ... ] section in your relations style file. For
example:
type=route route=bicycle network=tcn
{
name '${ref|subst: |highway-symbol:box} ${name}' |
'${ref|subst: |highway-symbol:box}' | '${name}';
apply {
set routable_way_generated=yes;
set cycleroute_from_relation=yes;
set access=yes; set motorcar=yes; set motorcycle=yes;
set bicycle=yes;
}
} [ 0x02 road_class=2 road_speed=1 level 3 ]
All the ways that belong to that relation are converted into the given type.
This is done before and in addition the processing using the lines style file.
As you can see you can modify the tags of the ways that belong to that relation
to avoid generating ways twice by using an appropriate condition in the lines
style file.
Regards
Thilo
Am 26.03.2010 um 23:55 schrieb Chris-Hein Lunkhusen:
Marko Mäkelä schrieb:
So, I choosed the simplest solution and mapped the line
as route=shuttle_train.
You could set this attribute in the relations file too.
But in this case the problem of the connections to the highway network
on the railway-crossings remains.
If the route is too complicated(!?) MS switches to direct-line routing. :-(
Sorry, I have no idea about that. The Edge 705 often cheats in bicycle
navigation by jumping to car road after a few km, but I haven't seen it
switch to direct-line routing yet. But you have a much higher way density
I guess.
I played a little bit with the lines-style-file, changed the road-class
from 0 to 1 for residential, unclassified and service and now
the routing is fine.
So maybe roadclass 0 is not good for routing
Chris
___
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] Display of railways
Hi Adrian, Am 30.01.2010 um 23:40 schrieb Adrian: Another Garmin foible... Sightly off-topic, but I thought this was the best place to post this information. I have a Streetpilot c550 and an etrex Legend HCx. On both, the last zoom setting at which railways are visible is 800ft (resolution 23) with normal detail setting. I have discovered that the receivers override the resolution which is set in the map (usually around 18). Why have Garmin done this? Does someone at Garmin not like railways? RoadTrip does respect the resolution which is set in the map. For some receivers it is possible to set the resolution for which railways are visible on the receiver itself. My guess is that they forgot about that feature when they removed this option on the receiver and now it is stuck to 800ft. My solution is the same as yours, to use a different ID for railways. This works also with routable maps, because there is no routing via railways. I have worked around this by changing the line type used for railways. I make the new line type look like a railway, with a .TYP file. I use type 0x10 in a non-routable map, and this works as expected. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
Am 29.01.2010 um 17:47 schrieb Christoph Wagner:
Thilo Hannemann schrieb:
The reason why you need a matching polygon rule for POIs to be generated is
that mkgmap needs this to find out that it is a polygon.
Now I really understand the problem. Would it be enough for mkgmap to specify
a rule in polygons-file like this:
building=*
without any actions and typemappings, just to find out that building is a
polygon tag and get a point out of it?
I don't know, but I think it won't work. mkgmap might complain about the
syntax, so you could try
building=* { set dummy=dosomething }
instead. But actions alone don't invoke the code for the polygon creation at
all IIRC, so that probably won't work either.
You could try to patch mkgmap so you can have a dummy type that won't trigger
the creation of the actual polygon. Maybe that's what happens if you specify a
type that can't be converted into any Garmin type (say 0x) anyway. So
it would be
building=* [ 0xff resolution 24 ]
or something like that. On the other hand - if the code checks the validity of
the Garmin type mkgmap will complain, if it doesn't check it the resulting map
will probably be broken.
Regards
Thilo
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --add-pois-to-areas behaviour
The reason why you need a matching polygon rule for POIs to be generated is that mkgmap needs this to find out that it is a polygon. Why is this? Because there is no way to find out whether a closed line is actually a polygon or a line/way besides looking at the tags. From the OSM standpoint a polygon and a line/way are the same. You can't even claim that only polygons are closed, because ways can also be closed (just think about roundabouts). So mkgmap looks whether it finds a matching tag in the polygons style file and if it does it is handled as a polygon. Then it looks at the lines style file and if it's there it is a line. And AFAIK there is actually a check whether there is a matching POI already inside the polygon. And besides that, I consider the style handling as it is currently done mostly broken. A complete rework (think style branch) is highly welcome, even if I have to rewrite all my style files and patches. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Split barrier=* and traffic_calming=* to a separate layer?
I'd also think that the multi-layered approach would add a whole new level of complexity to mkgmap. And it is a feature that no official Garmin map has ever used AFAIK. You even get different results depending on your MapSource *version*. So I don't think it is a something that should be built into mkgmap. But on the other hand some contrib section would be great. I'd happily donate my scripts for that (they are already available via launchpad.net/radkarte). Some repository for TYP files would also be great. Regarding the script language I'd recommend ant buildfiles. They are portable and everybody who builds mkgmap from source has ant installed anyway. Regards, Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mp: PATCH] Multipolygon handling - decomposed polygons
AFAIK the POI searches work only with the actual POIs that are generated, not the polygons. So this should be no big problem. You should make sure though that the --add-pois-to-areas option doesn't generate the POIs twice. Regards Thilo Am 09.01.2010 um 11:56 schrieb WanMil: Am 09.01.2010 11:25, schrieb Ralf Kleineisel: On 01/09/2010 10:08 AM, WanMil wrote: Another idea is to add some specific tags by the mulitpolygon algorithm that link to the other pieces of the formerly big forrest. This could be evaluated by the SizeFilter? Another idea (don't know if this is possible): You have a big multipolygon forest. You could duplicate it. One copy without small inner polygons for the low resolutions. Another copy with the inner polygons which gets splitted for the higher resolutions. The copies could be marked with some mkgmap internal tag and used later. That should be no problem for the mulitpolygon code. But I need someone who can modify the style handling. What about POI searches? If we have multiple versions of the famous Wienerwald the search for forrests should return only one version. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Suggestion - Make Douglas Peucker Algorithm more Configurable
The problem with the roads is that the SizeFilter is called for lines as well as for polygons. But the call to the filter is in two different places in mkgmap/build/MapBuilder.java. So if you make the MIN_SIZE a parameter and use different values for lines and polygons you won't have any holes in the roads at all and can set MIN_SIZE to a bigger value for the polygons. Regards Thilo Am 08.01.2010 um 15:52 schrieb Felix Hartmann: On 07.01.2010 23:13, Thilo Hannemann wrote: The Douglas Peucker Algorithm might not be the best way to tackle the problem of too small polygons. Right now polygons will be dropped if they have a maximum extension of less than one map unit at the current resolution. The code is in mkgmap/filters/SizeFilter.java if you want to try it, just set MIN_SIZE to a value greater than one should do it. The proper solution would be to merge polygons if they overlap at the current resolution. Otherwise we might get holes in forests if they are mapped in small pieces. But I have no idea how to implement that... I just set it to 8 to see the effects. a) it also removes many road pieces on low resolutions - so there are pretty big holes in roads. b) it is much much faster both in Mapsource as on my vista hcx. So concluding from that little try, yes having some algorithm joings roads and polygons (and dropping very small polygons) would mean a huge speed increase (and joining should not care for name or ref on resolution 18 or below). Actually already setting MIN_SIZE to 2 makes a noticeable speed improvement and only a very few holes do appear. I will leave it at 2. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Suggestion - Make Douglas Peucker Algorithm more Configurable
I've tried the patch as well and it works nicely. Smaller maps, some map clutter removed and seems to be faster as well. Regards Thilo Am 08.01.2010 um 21:48 schrieb Johann Gail: Felix Hartmann schrieb: That patch works pretty nice. I upped the value to 40 and that gave nice results when zoomed far out. Here is the settings that I would find optimal resolution 24 == 4 (I think 4 is anyhow the minimum because if less than 4 pixels than it ain't an area) resolution 23 == 6 ( resolution 23 is not used by all GPS devices if resolution 24 and 22 are present) resolution 22 == 6 resolution 21 == 20 resolution 20 == 40 resolution 19 == 80 resolution 18 == 120 Just to be sure there is no missunderstanding: You are not able to set minsizes for each resolution. You haven't set them, or have you? The SizeFilter itself should shift the minsize according to the resolution. I.e. if you init it with number 2 the following minsizes should be uesed: resolution 24 = 2 resolution 23 = 4 resolution 22 = 8 resolution 21 = 16 resolution 20 = 32 resolution 19 = 64 resolution 18 = 128 which matches roughly your demands. ___ 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] Suggestion - Make Douglas Peucker Algorithm more Configurable
The Douglas Peucker Algorithm might not be the best way to tackle the problem of too small polygons. Right now polygons will be dropped if they have a maximum extension of less than one map unit at the current resolution. The code is in mkgmap/filters/SizeFilter.java if you want to try it, just set MIN_SIZE to a value greater than one should do it. The proper solution would be to merge polygons if they overlap at the current resolution. Otherwise we might get holes in forests if they are mapped in small pieces. But I have no idea how to implement that... Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Suggestion - Make Douglas Peucker Algorithm more Configurable
Am 07.01.2010 um 23:22 schrieb Johann Gail: The proper solution would be to merge polygons if they overlap at the current resolution. Otherwise we might get holes in forests if they are mapped in small pieces. But I have no idea how to implement that... Which would be rather counterproductive to the PolygonSplitter code :-( The polygons gets split to not hit any limits. Not necessarily. With merging the polygons I meant to merge *what you actually see* on the map. That is also what makes it so hard, because the polygons will have no common points or even a common border, it just happens that they will overlap when displayed at a certain resolution. Seems, we need a complete new concept in handling polygons and multipolygons. Maybe we need to rasterize the OSM polygons to a bitmap and then create the Garmin polygons from that? Would be lots of work though (programming and computing/memory wise)... Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DP Filter and areas at Resolution=24
One idea for rounding at that level: Most annoying is that rectangles that are buildings aren't rectangles anymore after rounding. As the OSM data in itself probably isn't accurate at the 2 m level perhaps we could do tweak the coordinates so that rectangles stay rectangles (I know, the projection has an influence as well)? This would make the maps much better looking. Any thoughts about that? Regards Thilo Am 26.11.2009 um 11:47 schrieb Johann Gail: Felix Hartmann schrieb: Mark Burton wrote: Hi Felix, Could the DP Filter not remove any points at resolution=24? It doesn't do anything at that res. At the moment it does nothing, but I'm not sure, if it SHOULD do something at this level, as there may be well some points to delete. Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support. okay I see. So the only real solution would be to have intelligent filters moving the nodes to nearest 2m in such a way that there is minimal loss of detail. Probably pretty CPU intensive and a lot of work. So we have to live with it, in most places there is no real loss of information anyhow. I have thought of some ways to merge the rounding filter and the dp filter for this reason. Mabe the dp filter should take into account the distance to rounded coordinates, not the real one. Or maybe it would be better to insert the rounding filter AFTER the dp filter. It may be possible to achive a little improvement, but I doubt it. The main reason is the limitation of resolution to 2m. Regards, Johann ___ 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] tag test start with
Hi Ben,
perhaps it is not really obvious from the documentation, but you can use
regular expressions. The syntax would be
name ~ 'T.*'
for example. Note the .* instead of a single *, this is a proper regexp and
not the simplified version. For reference I would suggest something like
http://java.sun.com/docs/books/tutorial/essential/regex/, but I'm not sure if
everything works in mkgmap that is described there.
Regards
Thilo
Am 25.11.2009 um 13:21 schrieb Ben:
Hi mkgmap gurus,
Im currently trying to convert some POI lists into img format with mkgmap.
Depending on the first character of the POI name, different actions
should be performed.
I tried the following:
name=T* {name '${name}'} [0x0101 level 4]
name=M* {name '${name}'} [0x0102 level 4]
name=E* {name '${name}'} [0x0103 level 4]
what results in the error message
Error in style: Error: (points:1): Stack size is 2
Could not open style null
As far as I understand the syntax, I can only test tags for equality,
not if they contain certain strings.
Does anyone have a good idea idea for how to achieve the desired
differentiation?
Thanks,
Ben
___
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] Which Nuvi?
Hi Mark, for collecting OSM tracks with your Nüvi you will want one where you can switch off the show on road behaviour. If you can't switch that off your tracks will always be exactly on top of the roads that are already in the map. Very much useless for OSM mapping. With my Nüvi 255W I don't see a way to switch off that behaviour (but perhaps there is some hack that I don't know of). Also all the nice options to control the tracklogging are missing, e.g. setting the point density. From the tracks that my Nüvi captures it seems that the distance between the points is about 30 meters, that is very far apart for OSM mapping. So I think at least the Nüvi 2xx series is useless for mapping. But using the mkgmap-generated OSM maps on them works fine. They do support the day and night modes (the Oregons for example doesn't), true color display (this is missing from the eTrex series, they only have 256 colors) and have an easily accessible SD-card slot (2 GB cards work, maybe more). I don't know about marine POIs, those are probably not supported well (but I don't know). Other than the Oregon for example it doesn't have a dedicated marine mode. Hope that helps. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Am 21.08.2009 um 12:43 schrieb Felix Hartmann: Is noone else using these features? Thilo, what about you? Are you able to use 1140 as a base? Hi Felix, sorry, I didn't see that thread earlier. The feature with the relations that you are using was never integrated into trunk. I assume that it is the generate_ways_from_relations.patch that I posted some time ago on this list. I'm using it, but it probably doesn't compile with 1140 right now. Too much has changed. I'm still busy with the merging of similar ways patch so that I don't update mkgmap for now, but stay at revision 1136. It would be too much work to keep all my patches in working order with relevant code files of mkgmap changing all the time. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Am 19.08.2009 um 22:01 schrieb char...@cferrero.net: I've created a partial list for the GPSMap76Csx though my aim was slightly different (I wanted to understand what symbols the hex codes translated into). Is there any way we can fork this page into separate pages per unit otherwise it will get very unwieldly as more GPSr are added? Yes. The advantage of the current format is that one can easily compare the different units. I'd hate to loose that ability. But I must admit that editing that page isn't nice. What I do is to copypaste everything into a text editor, edit there and copy the result back. It might help to divide that page into ID ranges, so that there isn't that much text to edit at once. Also the text could be a little smaller and still be readable. So if you have a good idea just do it. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Am 19.08.2009 um 22:17 schrieb Simon Josefsson: How do I use the test-map:all-elements feature? (I have a problem with highway=service roads on my Legend HCx when it uses Swedish, it labels the roads as Allé which I suspect is a mis-translation of Alley -- solving this might require firmware fixing though..) When invoking mkgmap, instead of giving it all those *.osm files, you just use test-map:all-elements as the input file name. This is a virtual file so to speak and will generate the test map. Normally it is centered around London, which might be not what you want. By setting the *environment variables* BASE_LAT and BASE_LON you can place the test map at any coordinate you like. How you set environment variables depends on your operating system. On a Mac (using the standard bash shell) and also on Linux with the bash shell you can use export BASE_LAT=... and export BASE_LON=... to set it in the terminal. You'll have to use the same terminal to start mkgmap, because the environment variables are separate for each terminal. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Make --add-pois-to-areas default?
Am 16.08.2009 um 23:14 schrieb Nop: Thilo Hannemann schrieb: One feature, one OSM-object Don't place nodes in (equally labelled) areas just to see some icon appear on the map. The renderers will display icons on areas as well and there's no need to have every parking-lot, soccer-ground etc. twice in the database. It is not true that all renderers will display icons for all areas. Not yet perhaps. It is also very questionable whether all renderers will always provide a meaningful positioning of automatically created icons, e.g. a simple approach will place the icon for an L-shaped area outside of the area. If a simple approach won't give the desired result we should implement a better approach. This has to be done only once for the renderer(s) and not for all the items in the database. We do not tag for the renderers. applies here. I think that a manually placed POI is always preferrable over an automatically created one and the wiki is oversimplifying things here. Actually this rule allows you to have manually placed POIs. But then you should not have the area labelled. And I think that is reasonable. Because otherwise a lot of items get duplicated in the database without any reliable way to determine whether they are duplicates or not. Therefore, I think the current algorithm for the add-pois-to-areas is sufficient, because it will correct most instances of those duplicate tags, which are errors in the database and should be corrected in the database anyway. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Merge similar lines and ways
Hi Mark, Am 15.08.2009 um 13:45 schrieb Mark Burton: However, looking at the code it seems to me that the merging happens after StyledConverter.addRoad() is called and that is where the way lengths are limited. So you either have to do the merging earlier, or you need to add a constraint to limit the length of the merged way. I see what you mean. Damn. I assumed that the length limiting would only occur in the filters later on. Thank you for pointing this out. I will modify the code that the merging is applied even earlier. Shouldn't be too hard to do. @Chris: If not - where can I download the patched versions? You can download a version of mkgmap with all the patches that I do apply from http://wiki.openstreetmap.org/wiki/User:Radfahrer/Radkarte (it's in German though, it's the second link in the section Entwicklung: Ausserdem sind die Stil-Dateien, die TYP-Datei und das gepatchte mkgmap auch -hier- verfügbar. The current version has the patch in it, but as discussed above this patch is buggy. Also beware that this is no official version of mkgmap, so please don't ask for support for it on this mailing list. The mkgmap I use is heavily patched and by asking about problems with it on the mailing list you will only tie up resources for bugs that the official version of mkgmap doesn't have (and with that therefore nobody can help you). The better approach is to wait until the patch makes it to trunk, which it will or will not, depending on whether the maintainers deem it beneficial or not. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope (simplifyWays patch V8)
I'm currently working on it. Have you tried the patch together with routing? In my trials the routing was completely broken after applying the patch. That is because the merging is done *after* all the routing info is generated. So if two ways are merged into one, the references in the routing part of the map point nowhere. Also the turn restrictions break, because they also refer to the unmerged ways. I'm trying to apply the merging *before* the routing info and the turn restrictions are generated, but up to now I run into all kinds of trouble doing that. I hope I get it working soon, but if you like to work on it as well I can post my current diffs. Regards Thilo Am 12.08.2009 um 17:10 schrieb Clinton Gladstone: On Sat, Jul 25, 2009 at 3:55 PM, Johann Gailjohann.g...@gmx.de wrote: Find attached an patch of my working copy. It is based mainly on my old simplifyWays patch. Its diffed against the current R1102. The main idea is to merge the lines directly before input them to the filters. It improves drawing speed on my etrex considerably on very low zooms. I'm not sure, if it is the optimal place to do the merging, but it seems to work. I tested this patch, and it seems to work well. I have not yet thoroughly tested it, and I have not done a speed comparison, but I think the patch is quite worthwhile. Are you considering further work on it, or getting it committed? Cheers and Thanks. ___ 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 v2] - styling for the power user
Hi Mark, Am 06.08.2009 um 23:52 schrieb Mark Burton: I disagree. The patch simply provides a means for those people who have complex styling requirements to roll their own styling engine so they are not obliged to use whatever is built into mkgmap. The presence of the patch will not affect the development of the mkgmap styling system but by providing people with an alternative mechanism, it will encourage innovation and new thinking. One could argue that mkgmap would be better off having no styling function at all and it should focus on the core task of converting an input dataset (styled OSM) into map files (.img, etc.) The problem here is that in the end you cannot separate the styling from the map conversion process. When I started using mkgmap I also used preprocessing. But then I found that my preprocessor had to duplicate a lot of the functionality of mkgmap to do it right. For example finding all the ways that belong to a relation. It was much easier to patch mkgmap to get the same results, because all that information is already accessible there. But of course one could argue if this convenience is a reason in itself not to separate styling and map conversion. Some thoughts about styling: ... Well it's not what I would do. Ok. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - styling for the power user
Hi Mark, Am 06.08.2009 um 21:49 schrieb Mark Burton: The way I see it is: 1 - the mkgmap style engine is good for moderately complex styling. 2 - for more demanding styling, either the mkgmap style engine has to be fixed/enhanced to support whatever new demands people want to make on it, or ... 3 - we can provide some simple hooks whereby you can do the styling with some 3rd-party application (not mkgmap) as a pre-processing step. thank you for your effort, but I would go with the the mkgmap style engine has to be fixed/enhanced approach. Of course you could add preprocessing, but that is already possible now (think mp-files). By proposing preprocessing you just divert programming power away from mkgmap - everybody starts his own preprocessor instead of improving mkgmap. This will make decent mapmaking for starters even more complicated as it is now. Some thoughts about styling: What we see right now is the move from a conversion table to a macro/programming language. As you say, the style files were never intended to be able to do the things we want them to do now. So what can we do about that? We could improve them until they are Touring complete. But I don't think we should. Because then we would only create another programming language with another syntax and all the problems that arise from that. What I propose is to keep the style files, perhaps even *stripping* features from them (action rules, default_name). To implement all those nifty new tricks I'd like to have a plug-in interface in mkgmap to add my own Java routines. That could be plug-in at compile time, no need to make it too complicated. It would be a start to sort through all the classes and provide some documented hooks to plug-in your own routines. Then in the style files one could invoke the plug-ins that one would like to use. An excerpt of the lines style file might look like this: highway=secondary [0x04 namefinder=default_highway filter=DouglasPeucker(keep_junctions_fixed=true) routebuilder=default_routable(road_class=2, road_speed=3) resolution 20] natural=coastline [0x15 namefinder=fixed(name='coastline') filter=DouglasPeucker resolution 12] By selecting the namefinder, the filter, the routebuilder etc. one has complete control about how the data is processed. The routines could accept parameters in parantheses behind their name for added flexibility. Some (standard) routines are supplied, but it should be easy to add your own. By having a defined interface it gets easier to interchange improvements - currently the patches need often quite some work to get them to compile all together. By partitioning the work between routines each one can be relatively simple. So for example one namefinder routine could just be responsible to find a name for a highway. Another one could be responsible to generate a name for a POI for a building that has address information. This will also mostly eliminate the need for action rules. As I think the action rules code is - say - quite complex, this might remove one area of oddities. By keeping the style files and out-sourcing the complex programming into Java plug-in-routines the style programming stays simple for the users that only change the style files themselves, but power-users can still program everything they like in plain Java. As the plug-in routines can be selected from the style files, the regular-users can also benefit from the work of the power-users, even if they can't program in Java themselves. Any thoughts about that? Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter build fails on mac
There is an application called Java-Einstellungen (probably Java- Setup in English) that is part of MacOS 10.5 (or the Xcode tools, don't know). I just changed the setting there and everything worked fine. No need to fiddle with frameworks and environment variables. Regards Thilo Am 05.08.2009 um 11:06 schrieb Clinton Gladstone: On Wed, Aug 5, 2009 at 2:24 AM, Greg Troxelg...@ir.bbn.com wrote: (This is also splitter-dev I think.) I am trying to build the splitter on a mac (10.5.7 with java 1.6.0_13, 64-bit server VM), and failing. I have successfully built mkgmap and run it, so my java setup is mostly ok. I regularly build splitter in a similar environment to yours. I have to be very careful to make sure that I use the 1.6 Java compiler (not just the JRE) when I do this. If you have just adjusted the symbolic link to java 1.6, this will not be sufficient to compile with 1.6 I don't have my Mac in front of me right now, but I believe I set the JAVA_ROOT (or similar) environment variable to the 1.6 framework. As Chris also mentioned, I'm almost certain that you're compiling with 1.5. Cheers. ___ 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] Putting the DP code under the microscope
Hi Johann, Am 25.07.2009 um 10:54 schrieb Johann Gail: A further development would be, to consider only nodes which are visible crossings at the current zoom level. I.e. if a residential connects to a big road and the residential is not visible at the current zoom level, then it is allowed to zap this node. This would straighten out lines at low zooms much more. But at the DP filter code I don't have this information available. Yes, that would be the best way. But one would need to change a lot of the underlying code to make it happen, as currently only the number of highways that use a node is stored, but no reference to which highways that are. Changing this would be a major act unfortunately. About the error distance: What I still experience is that the lower resolutions look bad in the maps. It seems that the ways get too much simplified for lower resolutions. It seems almost like a scaling problem with respect to the resolution. I reduced the error distance to 1/8th of the resolution and that brought some improvement in the higher resolutions (20, 22). But if I look at the lower resolutions (down to 12) it gets worse and worse. Looking at the DP code I can't find any hint why that should happen, so it might happen somewhere else? I have no clue. Btw.: there is another patch around, which merges lines before DP filtering them. This is reasonable for the highways at very low zoom levels, which could be simplified often to a sinlge line in the overview maps. (But only if they are not cut in segments from exit to exit). If I find some time I will release an updated patch for it. this is very interesting. I was planning to implement something likes this for some time, but didn't get around to do it. But not so much for display, but for routing. I think the routing could be much improved if we would merge ways, especially for bicycle routing, where the cycleways consist of tiny bits here and there. The routing algorithm in the Garmin units then won't find a nice route, because it gives up trying to wiggle its way through the short bits. Instead it takes a long way that goes into the general direction of the destination. Which often happens to be a major road that you don't really want to use while cycling. The cycleway going alongside it isn't used, because the routing algorithm doesn't find it. So if you have that patch available please post it. Even if it doesn't work against the current trunk I'll happily try to make it work. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope
Hi Felix, Am 25.07.2009 um 13:05 schrieb Felix Hartmann: Yeah, merging roads if possible would be great. Even more important would however be smoothing of curves. i.e. make serpentine corners on mountain streets more smooth, because otherwise if there is a say 160° corner, it will add a big time penalty, which in a car is more or less correct, but on a bicycle overrated. This is actually not that difficult, because you can do it with an additional filter for the ways. It is a local modification for each way. However, how do you want to do the merging without loosing attributes (i.e. roadname changes, bridge, etc..), I think this could only work by running after the main processing, and merging everything identical if possible. Otherwise before merging there needs to be a check whether there is not a rule in the style-file that would change either the name of the road OR the type (0x??) of a road. If both not changed then merge it. The trick would be to do the merging on the data just before it is converted into the Garmin format, after the style files are applied. Then you have the final settings of all attributes and the name and can merge only those ways that are identical in that respect. This is also the point when the filters get applied to the ways. The problem here is that the filters see only each way in turn, so they can only perform modifications on a single way. Unfortunately it is not that easy to find a place in the source code where you could apply the merging of ways, which is the reason why I haven't had a go at it yet. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope
Hi Johann,
it is actually not what it seems to be. The douglasPeucker function is
called recursively. If the condition (maxDistance allowedError) is
fulfilled, the current part of the way can be reduced to a line (in
case start- and endpoint are different points) or a point (in case
start- and endpoint are the same). So the if (ab == 0)
points.remove(endIndex) does not remove the endpoint of the whole
polygon, but only prevents the polygon to have consecutive identical
nodes if the original way has small loops in it. Wouldn't be that
uncommon for contour lines btw. Closed polygons stay closed unless
they are smaller than the allowedError, in which case they will reduce
to a single point and will be dropped later anyway.
Some other observation about the DP code: I'm currently using the
Straight version instead of the Node version and I think the maps
look much nicer if zoomed out. I would recommend this as the standard
setting. The problem of T-crossings not lining up isn't that
prominent, because in resolution 24 the DP won't be applied at all and
in the other resolutions it is not that much noticeable (for me at
least).
Regards
Thilo
Am 24.07.2009 um 23:11 schrieb Johann Gail:
Thilo Hannemann schrieb:
Here is another approach to the lost last point. The Douglas
Peucker
filter is improved so that it can deal with identical start- and
endpoints. If the start- and the endpoint are identical, the
algorithm
calculates the distance between these identical points and the point
p. So the polygon is not split at point N/2, but at the point that
has
the greatest distance from the start-/endpoint.
Dealing with the problem in the Douglas Peucker algorithm itself has
the advantage that it will also work for a pathological polygon or
way
that has identical, non-consecutive points in the middle of it.
Hi Thilo,
I was just trying to get your patch working and would like to test it
afterwards.
In general I find it a good one.
But I'm not sure about the last lines of your patch. If you delete the
endpoint in case of ab==0 then you introduce the original problem
again.
The problem was polygons loosing their start or endpoints.
What are your thoughts about it?
Greetings,
Johann
@@ -148,6 +154,12 @@
}
else {
// All points in tolerance, delete all of them.
+
+// Remove the endpoint if it is the same as the
startpoint
+if (ab == 0)
+points.remove(endIndex);
+
+// Remove the points in between
for(int i = endIndex-1; i startIndex; i--) {
points.remove(i);
}
___
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] Patch so that the --add-pois-to-areas option applies actions defined in the points style file and takes the POI name from there
This one is a little complicated: When using the --add-pois-to-areas option, for every shape whose tags will match an entry in the points style file, a POI entry in the map will be created in the center of the shape (if there is not already one POI with the same name inside the shape). The POI will have the name of the *shape* and no actions from the points style file will be applied. I think that is not how it should be. One of the most important cases for this option is when you have an POI that is in the OSM data as a building (close way with building=yes) carrying the tags for the POI. You might now have lots of name-tweaking rules in you points style file to generate nice looking names for hotels, etc. But in the polygons style file there is a single entry that handles all tags with building=yes. What you now get is that all the name-tweaking rules *are not applied* if the POI comes in the form of a shape, only if it comes as a single node. To get around this you had to duplicate your name-tweaking for each POI in the polygons style file. This will need lots of rules that from the perspective of the polygons style file all will do the same: generate a shape for a building. So this patch will modify the behaviour so that a POI that is generated from a shape will have all the actions defined in the points style file applied to it and that it will also get the name defined by the points style file. modify_generate_pois_from_areas.patch Description: Binary data Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Creating contour lines from DEM data
Hi Christian, congratulations, that is very good work. As there are some people on this list who will publish their created maps I'll have to add a caveat though: You should make sure that the data source you use for the generation of the contour lines is compatible with the OSM license. See http://wiki.openstreetmap.org/wiki/Legal_FAQ and http://wiki.openstreetmap.org/wiki/Common_licence_interpretations. The reason why I bring that up is that for example the improved SRTM data by CIAT-CSI is in my opinion *not* compatible with the OSM license! Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option preserve-element-order
Hi Felix, you say that the draw order of the polylines depends on 1. type and 2. id. What do you mean by id? Is that the OSM id? Or do you refer to the order the lines are written into the .IMG file? From what I see it certainly depends on the type of the polyline, but in a way that I do not understand. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Re: Questions related to practical usage of MKGMAP
I've attached Toby's patch. I'm using it and it works well, *if* the
polyline is long enough. When using it for cycleroutes for example
they tend to be made of lots of tiny pieces and the road symbols won't
be displayed.
highwaysymbols.patch
Description: Binary data
Another patch you might be interested in is the
generate_highways_from_relations patch. This allows to write
something like
type=route route=bicycle network=tcn [ 0x02 road_class=3
road_speed=6 level 3 ]
into the relations file. It will generate a copy of all the ways that
belong to that relation. The ways will get joined together, so that it
is not lots of tiny pieces, but only as much ways as there are non-
continuous parts of the route.
generate_ways_from_relations.patch
Description: Binary data
Another patch: bugfix_overlays. When using overlays and routing, the
routing information is added once for each of the overlayed Garmin
types without this patch. This is unnecessary, because the overlayed
ways differ only in the Garmin type, but nothing else. Also a copy of
the points that the way is made of is created, instead of simply
copying a reference. Without it there was some weird behaviour, but I
cannot put my finger at the reason for that.
bugfix_overlays.patch
Description: Binary data
And finally one patch that you might want to apply: start-with. This
adds a text filter for variable substitution. You can say for example $
{name|start-with:Hospital }. This will put the string Hospital in
front of the name, but only if that string doesn't contain Hospital
somewhere already. Note that the trailing space of Hospital gets
trimmed for the search. It is really useful for POIs, especially if
you have different types of POIs that will all get displayed in the
same category on the GPS. For example hotels and hostels. With start-
with you can make sure that the string Hotel resp. Hostel is part
of the name, so that you can distinguish them in the search results on
the GPS.
start-with.patch
Description: Binary data
Regards
Thilo___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ASTER elevation data
Hi Christian, Am 30.06.2009 um 23:33 schrieb Christian Gawron: I already wrote a class to read SRTM data directly with mkgmap, i.e. without having to create the contours as separate (huge) files. This is very much encouraged. For the contour lines the computing times may be that long that it makes sense to have separate files (I'm doing contour lines for Germany in octave and it takes about half a week - and the contour function in octave is programmed native, not in octave script itself). What this is also good for is to calculate the inclination of roads, which in turn would be very nice to have for bicycle routing. So as soon as you have something working I'd like to have a look at it. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Option preserve-element-order
Has anybody had success controlling the drawing order with the -- preserve-element-order option? The drawing order is random for me, with or without this option. Would be nice to get it working, though, especially for overlays. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Find Places items from test-map:all-elements
Hi Marko, I've started to compile a list of the behaviour of different GPS units with regard to POIs. As the different units handle the POIs differently it is important to have such a list, because what displays on your GPS unit just fine might be invisible on a different unit. For now I added the information about the Oregon 300 and partly about the nüvi 255W. It would be great if you could add your findings about the Edge. You'll find the list at http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope
Here is another approach to the lost last point. The Douglas Peucker
filter is improved so that it can deal with identical start- and
endpoints. If the start- and the endpoint are identical, the algorithm
calculates the distance between these identical points and the point
p. So the polygon is not split at point N/2, but at the point that has
the greatest distance from the start-/endpoint.
Dealing with the problem in the Douglas Peucker algorithm itself has
the advantage that it will also work for a pathological polygon or way
that has identical, non-consecutive points in the middle of it.
Index: src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java
===
--- src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java
(revision 1067)
+++ src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java
(working copy)
@@ -60,20 +60,11 @@
MapLine line = (MapLine) element;
+ // Create a new list to rewrite the points into. Don't alter the
original one
ListCoord points = line.getPoints();
- int n = points.size()-1;
-
- // Create a new list to rewrite the points into. Don't alter the
original one
- ListCoord coords = new ArrayListCoord(n);
+ ListCoord coords = new ArrayListCoord(points.size());
coords.addAll(points);
- // If the first point is identic with the last one (a polygon),
drop it
- // Otherwise douglasPeucker will not work!
- while ((n 0) coords.get(0).equals(coords.get(n))) {
- coords.remove(n);
- n--;
- }
-
//#if (Node version)
//Dont touch Coords, which are nodes.
//So points at croosings will not be moved
@@ -129,18 +120,33 @@
Coord b = points.get(endIndex);
double ab = a.distance(b);
- // Find point with highest distance.
- for(int i = endIndex-1; i startIndex; i--) {
- Coord p = points.get(i);
- double ap = p.distance(a);
- double bp = p.distance(b);
- double abpa = (ab+ap+bp)/2;
- double distance = 2 * Math.sqrt(abpa * (abpa-ab) * (abpa-ap) *
(abpa-bp)) / ab;
- if (distance maxDistance) {
- maxDistance = distance;
- maxIndex = i;
+ if (ab == 0) { // Start- and endpoint are the same
+ // Find point with highest distance to start- and
endpoint
+ for (int i = endIndex-1; i startIndex; i--) {
+ Coord p = points.get(i);
+ double distance = p.distance(a);
+ if (distance maxDistance) {
+ maxDistance = distance;
+ maxIndex = i;
+ }
}
+ } else {
+ // Find point with highest distance to line between start- and
endpoint
+ for(int i = endIndex-1; i startIndex; i--) {
+// Calculate the area of the triangle a-b-p using Heron's
formular. The height of
+ // that triangle is the distance we look for.
+ Coord p = points.get(i);
+ double ap = p.distance(a);
+ double bp = p.distance(b);
+ double abpa = (ab+ap+bp)/2;
+double distance = 2 * Math.sqrt(abpa * (abpa-ab) * (abpa-ap) *
(abpa-bp)) / ab;
+ if (distance maxDistance) {
+ maxDistance = distance;
+ maxIndex = i;
+ }
+ }
}
+
if (maxDistance allowedError) {
// Call recursive for both parts
douglasPeucker(points, maxIndex, endIndex,
allowedError);
@@ -148,6 +154,12 @@
}
else {
// All points in tolerance, delete all of them.
+
+ // Remove the endpoint if it is the same as the
startpoint
+ if (ab == 0)
+ points.remove(endIndex);
+
+ // Remove the points in between
for(int i = endIndex-1; i startIndex; i--) {
points.remove(i);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
Hi Mark, Am 16.06.2009 um 08:33 schrieb Mark Burton: Recently, Coord.distance() was replaced with a much speedier implementation because a lot of cpu cycles were being wasted there. The newer function appears to be accurate enough for our purposes. The DP code contains another distance calculation. What you must calculate there is the distance of one point to a line. The Coord.distance() is used in that formula, but I do not understand the formula itself. Maybe it's some genius trick to simplify the calculation, but I do not get it. The only thing I see is that when I reduce the error distance the simplified ways look nicer. But the preset error distance of one half of the resolution should be small enough already. So my assumption is that the actual error distance is much larger than expected, which may be due to a bug in the code. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
Hi Mark,
Am 16.06.2009 um 09:18 schrieb Mark Burton:
At the distances we're (mostly) interested in, the curvature of the
earth's surface has a tiny effect (much less than the effect of
hills
valleys) so I guess (hope) that leaving out that factor is OK.
The curvature may have a tiny effect, but nonetheless you should
consider the coordinate system you are using. Interpreting lat and lon
as cartesian coordinates (don't know whether you are really doing
that) will give large errors at high latitudes.
I know that this isn't your code but it's as good a place as any
to comment about it: looking at the DP code (for the first time), I
immediately see that the loop that finds the max distance is
(potentially) doing many more sqrts and divisions than it needs to. So
even if the code is correct, it could be somewhat faster which would
be
worthwhile given that it gets called for every line. Eg, it could be
changed to look like this:
// Find point with highest distance.
// Loop runs downwards, as the list length gets modified while
running
for(int i = endIndex-1; i startIndex; i--) {
Coord p = points.get(i);
double ap = p.distance(a);
double bp = p.distance(b);
double abpa = (ab+ap+bp)/2;
double dd = abpa * (abpa-ab) * (abpa-ap) * (abpa-bp);
if (dd maxDistance) {
maxDistance = dd;
maxIndex = i;
}
}
maxDistance = 2 * Math.sqrt(maxDistance) / ab;
Also - you get a division by zero if ab is 0, perhaps adding a test
for that before the loop would be advisable.
Do you understand that formula for the distance calculation? If so
could you explain it for me? I don't get it.
Another minor nit - the comment is inaccurate as the list length
doesn't change in this loop.
It is accurate, because the list length does get changed by the way
the recursion works. It is not obvious, therefore this comment is
really needed!
Another question, just out of curiosity: Does it really mattern in
Java how many sqrts or sin or cos I do? Doesn't that kind of
difference get swamped by all that interpretation and memory
allocation things etc. going on? With modern FPUs that kind of
operation isn't that expensive (if it is done native).
I would start working on the DP code if it makes sense. If somebody
understands that distance formula and could explain it it would be
very much appreciated. Otherwise I will have to make up my own formula
(sigh...)
Regards
Thilo
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Filters for overview map
Hi, Am 16.06.2009 um 20:39 schrieb Elrond: My current conclusions from both thread parts: 1) I should only disable the SizeFilter (we really, really don't want to drop any polygon). For the overview map obviously not. 2) We should fix DP. From what you explained about the overview map (I was always wondering what it is for...) also DP for the overview map makes no sense. What would make sense though would be to split the tiles in a way that the polygons in the overview map need no rounding. Or is that already the case? And yes, we should fix DP (if it is actually broken). Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
Am 16.06.2009 um 18:33 schrieb Marco Certelli: Just speculation: I've a and b that defines a line. I look for the distance between a point p and the line. Given the triangle p-a-b where p is the vertex and a-b is the base, the area of the triangle can be calculated from the lenght of its 3 sides (pa, pb, ab). After that, since the area is also base x height / 2 we can calculate the height = area / base * 2 well, the height is exactly the distance of the point p from the line a-b Maybe... You are right. It is Heron's formula. And from what I see the implementation is correct. Even the coordinates on the sphere are no problem, because the formula itself doesn't use lat and lon and we can assume the triangle to be flat locally. So I think the implementation is quite clever indeed. Okay. But that still doesn't explain why the map looks better if I reduce the error distance setting for the Douglas-Peucker filter. The error should be already invisible at the default setting. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
Hi Elrond, there seem to be some problems with the simplification right now. But instead of simply de-activating the simplification I think we should debug the code. Of course it's fine to de-activate it for debugging :) The problem of distorted polygons does not only appear in the overview map, it appears at all zoom levels. One problem I could identify is that the Douglas-Peucker code does remove the closing node of a polygon, but doesn't put it back after simplification. This might be ok for filled polygons, but for contour lines it is a problem. I've attached the patch that I use to solve that problem. decrease_douglas_peucker_error.patch Description: Binary data That patch also sets the error distance for the Douglas-Peucker algorithm to 1/8th of the resolution instead of one half. In my opinion this gives much nicer results. The question here is why it is so, because you shouldn't be able to see such small errors. From looking at the Douglas-Peucker code I can not put my finger on any bug. What I do not understand is the distance calculation. Anybody with insight cares to have a look at it (or explain how it works?). I'd assume that a distance calculation on a spherical surface would involve lots of trigonometric functions - which the formula in the code doesn't. Take care Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] max-speed and arbitrary values
Hi Felix, Am 03.06.2009 um 12:06 schrieb Felix Hartmann: Is it possible to encode arbitrary maxspeed values or can we only set in steps of 10km/h? For example having road road_speed=7 associated with 35km/h, road road_speed=6 with 27, road_speed=5 with 23, road_speed=4 with 20, road_speed=3 with 17, road_speed=2 with 10 and road_speed=1 with 5km/ h. The difference this should make would be enough to only set road_class=2, 1 and 0 and avoid the big time penalties for sharp turns that happen in road_class 4 and 3. This would be great for bicycle maps. That would be great indeed. In Mapsource one can change the speed oneself, I noticed that dividing default speeds by a factor of 3.5 produces pretty good estimation of arrival times for bicylces (when using the car/ motorcycle setting, as bicycle produces rubbish routes) but on the GPS this is not possible. @Thilo, do you understand the code good enough to write a patch for this if possible.? I have problems understanding in which files the maxspeed is handled. I have not really looked into the Garmin encoding part of the code, but I could invest some time if it helps. From what I know there are only those few road_speeds available in the format. *But* maybe there is some part in the header where one can set what actual speed each road_speed corresponds to (this is pure speculation). Somebody mentioned also that the GPS units will learn the speed you are actually driving and use that for their calculation. If this is speculation or based on facts I don't know. At least with my Oregon 300 I doubt it: As I use it all the time with my maps I'm cycling always in the car mode. So far the ETAs are still very wrong. If the GPS would learn the speed they should become more realistic over time. Perhaps we can build a Wiki page somewhere where we can collect all hard evidence about the routing? How about setting up an artificial map that we can use to test the routing, ETAs and so on? Especially keeping in mind that there might be a difference between different GPS units, firmware revision and so on. If there are routing parameters that the GPS units learn about their users that would really f*ck up our tests. @Marco Certelli: You've already started some tests. If you could write down what you did on some Wiki page so that others can repeat your tests that would be really helpful. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] Generate copies of ways using the relations style file *Experimental*
The attached patch allows to generate ways from a relation. To do so
simply write the way generating statement into your relations style
file, e.g.
type=route route=bicycle network=tcn { name 'Touristic
cycleroute' } [ 0x02 road_class=3 road_speed=6 level 3 ]
generate_ways_from_relations.patch
Description: Binary data
If one way is a member of several relations one copy of the way will
be generated for each relation (and also another one if the way
matches also in the lines style file).
The name of the generated way is the name of the relation. The access
tag must be set explicitly in the relations style file, as (except the
oneway tag) no tags are copied from the original way into the
generated way.
I consider this patch experimental, but as I have it in use now for
some days and it works fine I though I might publish it. It is really
useful for cycle maps.
Regards
Thilo___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error with austria.osm.bz2 of June 1 (all other contry extracts by gefabrik for Europe compiled except for Austria)
Hi Mark, I tried to do so, but the small file was processed without error :(. The big one is available at a website though (http://osm.arndnet.de/problem.osm.zip ). The problem to reproduce that error is that it occurs for me only if I merge contourlines that I generated on my own (not with srtm2osm). So this is quite a special case. I wouldn't have reported that error, but as I see that extremecarver sees a similar error I thought it might help. Regards Thilo Am 02.06.2009 um 08:50 schrieb Mark Burton: Hi Felix, Thilo, Is it possible to produce a small example OSM file that shows this problem? If so, please zip it up and send it to me or put it on a website I can access. Cheers, Mark ___ 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] maxspeed tag vs road_speed preset
Hi Marco,
the relationship between the maxspeed tag and the road_speed is
hardcoded in mkgmap. This is reasonable in general, because otherwise
the style files had to be much larger to cover all the possible
road_speeds per road. But if you want to use the road_speed in a
creative way (say for a cycle map) this gets in the way.
The evaluation of the maxspeed tag is implemented in src/uk/me/
parabola/mkgmap/osmstyle/StyledConverter.java. The following patch
will remove it.
Index: StyledConverter.java
===
--- StyledConverter.java(revision 1038)
+++ StyledConverter.java(working copy)
@@ -619,16 +619,8 @@
road.setOneway();
}
- // maxspeed attribute overrides default for road type
-
- String maxSpeed = way.getTag(maxspeed);
- int speedIdx = -1;
-
- if(maxSpeed != null)
- speedIdx = getSpeedIdx(maxSpeed);
+ road.setSpeed(gt.getRoadSpeed());
- road.setSpeed(speedIdx = 0? speedIdx : gt.getRoadSpeed());
-
boolean[] noAccess = new boolean[RoadNetwork.NO_MAX];
String highwayType = way.getTag(highway);
if(highwayType == null) {
Regards
Thilo
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [PATCH v1] Re: [mkgmap-dev] maxspeed tag vs road_speed preset
Hi Mark, It occurs to me that some people will want the maxspeed tag to override the speed code in the rules file (obviously, the person who wrote that code thought it was a good idea) but others, like Marco, would prefer not to have that feature. So, I guess, we need (yet another) option to control this behaviour. I attach a patch that does, essentially, the same thing as your patch with the addition that you can switch that behaviour on and off. Thank you for that patch. The patch I posted was intended to be applied locally if one wanted to remove that behaviour. With the state of mkgmap right now I think it is reasonable to hardcode such things as the maxspeed, because otherwise the style files will get overly complex and with the current syntax of the style files a lot of things can not be encoded at all (for example motorway exits, roundabouts etc.) For special map- tuning one will have to modify the mkgmap source. Which is probably even easier than coming up with highly complex style files to accomplish the same thing. So if you like to integrate the switch for the maxspeed handling into the trunk I will be happy, but I also understand that you might not want mkgmap to be cluttered with lots of special options. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
