Re: [mkgmap-dev] [index] Automatic location completion
I think this is caused by addr: tags that don't use the same spelling like the boundary multipolygons. Do you know about any similar name detection algorithm? So something like a sounds-like(String cityname) function? This would be necessary to fix that. I've used the soundex algorithm for similar problems in the past relatively successfully, however it's really only targetted at the English language. Another option might be to calculate the Hamming distance between the names and use some threshold to decide if they're equivalent or not. Wikipedia also has a page with some alternatives that might be of some use: http://en.wikipedia.org/wiki/Phonetic_algorithm ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] dropping place:village, hamlet, suburb in city search
Am 19.02.2011 07:08, schrieb maning sambale: The idea is to declutter the city search of these minor places and just the actual city/town will be used to index streets and cities. There would be a disadvantage: I assume the assignment of streets to cities works by searching the nearest place-node. This works better if taking the village und suburbs into account because the density is higher. I'm a littlebit amused that nobody seems to fully understand the location-autofill algorithm. ;-) Sould look into the source code but java isn't my mother language... Is there any solution for this problem? I finally build my first map with index option. When I search for streets or crossroads I can choose the Country and the city. I also found the City Dresden,DEU (http://snailrun.de/images/MapSearch/1.jpg), but also all suburbs, located in Dresden (Plauen in Dresden, http://snailrun.de/images/MapSearch/5.jpg). When I try to search for streets in Dresden I only get a few of them. When I search in Plauen, Dresden I find other streets. Thx ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1876: Only apply merge lines at lower resolutions.
Version 1876 was commited by steve on 2011-03-02 09:42:19 + (Wed, 02 Mar 2011) Only apply merge lines at lower resolutions. merge-lines is as discussed quite problematic, because it happens after the routing notes are placed, and therefore causes some problems. The closer you zoom in, the bigger these problems, while the further you zoom out, the bigger the speed improvement of using this option (at resolution 24 and 23 it makes basically no difference) and the smaller the problems (22 vs 24 means 1/4 of the wrong distance for info popup or jumping map when panning). This only has any affect if you are using the --merge-lines option. - Felix Hartmann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Global index branch
Found another bug in mkgmap-r1875. If I search for adresses on a Dakota, and skipping the place name (because often streets are assigned to the wrong place) and enter the streetname, the street is found but it points to a place in the Atlantic Ocean south of Ghana (lat0, lon0). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
Version 1877 was commited by steve on 2011-03-02 11:17:38 + (Wed, 02 Mar 2011) Allow different smoothing parameters for polygons and lines. It applies the DP filter against polygons with a different agressiveness than for lines. This is really useful because strong DP filter against lines looks really bad, while for polygons the visual quality is degraded less. Implements a new option --reduce-point-density-polygon - Johann Gail Documentation added to the help file - Felix Hartmann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sensible resolutions - (or patch 5)
On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote: Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. How hard would it be to merge nearby polygons on wider zoom levels? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sensible resolutions - (or patch 5)
On 02.03.2011 13:53, Marko Mäkelä wrote: On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote: Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. How hard would it be to merge nearby polygons on wider zoom levels? It would not work I think. What would be needed is to generalise polygons on lower zoom levels. Meaning merge them together, drop holes, straighten them (well the dp-filter already takes care of that), and have a seperate style-file where there are definitions on what gets merged how. Ideally a hole or scrub part of a forest would be only visible from resolution 24-22 or 24-21 (depending on the size of the whole/scrub). It's the same as you only want to see single houses when zoomed in close, when further away you want to see residential area, and when even further away you want to sea where is urban vs nonurban area. OSM sucks big in this regard and as long raster maps are the primary outcome of OSM data (for lower zooms) then there will be no motivation for change (change which means layering OSM data instead of one big black hole to sink information into). Marko ___ 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] Commit: r1877: Allow different smoothing parameters for polygons and lines.
Where can I find the help file? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1877: Allow different smoothing parameters for polygons and lines.
On 02.03.2011 14:11, Minko wrote: Where can I find the help file? help/en/options or showing it on commandline (see mkgmap on osm wiki). ___ 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] Recent crashes when searching on device
So could people confirm that when they see crashes they are not installing via mapsource, and what GPS device they are using? ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev I copy and paste the gmapsupp.img direct on to my Edge 605. I have never used Mapsource or the basemap on my 605 Cheers Paul ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Include the following patches into trunk -- Patch4 - decrease douglas peucker error
Okay I've done some comparisons between the two approximations. For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex). Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
On Wed, Mar 02, Felix Hartmann wrote: 1. If you have this error, please also check if link-pois-to-ways switch was used. According to a post here: http://forum.openstreetmap.org/viewtopic.php?pid=146242#p146242 the address search breaks down on Oregon once --link-pois-to-ways is used. It's used, rebuilding my map currently without that option and with mkgmap 1875 2. Check that the mgkmap version you are using to compile the maps, is the same or newer than the one that was used to create the maps. I always rebuild everything with the same mkgmap version. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inundated tile with no coastline
On 3/1/2011 3:38 PM, Nakor wrote: Hello, I have a tile with no coastline that shows up inundated. How can this be? How can I fix it? The tile is split us_midwest from geofabrick with: 4162: 2183168,239616 to 2215936,280576 # : 46.845703,5.141602 to 47.548828,6.020508 Thanks, N. Nevermind. This was a MapSource cache issue. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [index] Automatic location completion
Am 02.03.2011 04:52, schrieb Scott Crosby: This boundary is open by the coast side, as many others (¿all?) in Spain. Something similar to the close-gaps in the sea generation could do the trick. That's not a nice job to do... We might continue the boundaries along coastlines. This would be a job for a specialized BoundaryRelation class that inherits from MultiPolygonRelation. I have finished my checks with Spain and the result is perplexing: The splitted tiles do not contain any boundary tag. I have used splitter r164. The .pbf file does contain them. So it seems to be a splitter bug (or I have used it wrong). Ways that cross tile boundaries may be incomplete. When generating a tile, the splitter includes in each tile all of the nodes in the tile, all of the nodes within OVERLAP of the tile, and then any ways that use any of those nodes and finally any relations that use those ways or relations. If a way denoting a boundary has widely spaced nodes, where none occurs in the overlap region, the way will have a gap between the the last node in the region and the border. At present, it doesn't go back and 'fill in' missing nodes in those ways/relations, and it has never had that functionality. Doing that would require additional passes, but I think it could be added in a few days of work. Scott I was too quick with my guess that the splitter removes all boundary tags. It was my wrong search statement. Sorry! The real reason is, that multipolyong boundary definitions in Spain are tagged with type=boundary instead of type=multipolygon. Therefore the multipolygon algorithm does not handle them yet. @list: Should mkgmap handle type=boundary in the same way type=multipolygon? I vote for that. @Scott: I would be happy if there is a splitter option which ensures that all ways/relations are completely contained in a tile. That would improve the options we have to deal with the boundary information and would fix some multipolygon problems. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Countries issues
Hello, I built a map using us_midwest extract from Geofabrik and have 5 countries listed in the country list on my Etrex Vista: Country Israel Mongolia Ukraine United States Country seems to be when there is no info and I am fine with that. US is OK but I do not understand the other three. Below are example of cities that show up under those countries: Israel: Abbells Corners, Wis. http://www.openstreetmap.org/browse/node/153786773 Mongolia: Basswood Grove, Minn. http://www.openstreetmap.org/browse/node/151919152 Ukraine: Ackworth, Iowa http://www.openstreetmap.org/browse/node/151408706 Why does it happen? Thanks, N. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Countries issues
Nakor nakor@gmail.com wrote: Hello, I built a map using us_midwest extract from Geofabrik and have 5 countries listed in the country list on my Etrex Vista: Country Israel Mongolia Ukraine United States Country seems to be when there is no info and I am fine with that. US is OK but I do not understand the other three. Below are example of cities that show up under those countries: Israel: Abbells Corners, Wis. http://www.openstreetmap.org/browse/node/153786773 Mongolia: Basswood Grove, Minn. http://www.openstreetmap.org/browse/node/151919152 Ukraine: Ackworth, Iowa http://www.openstreetmap.org/browse/node/151408706 Why does it happen? Thanks, N. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Thanks for the very specific examples, it should be easy to track down from them. I'm on a train at the moment, but my initial guess is that regionOffset in LocatorConfig should be set. But there must be more to it than that. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Sensible resolutions - (or patch 5)
Am 02.03.2011 14:03, schrieb Felix Hartmann: On 02.03.2011 13:53, Marko Mäkelä wrote: On Wed, Mar 02, 2011 at 01:45:52PM +0100, Minko wrote: Negative consequence is that on Mapsource most of the forest disappears too soon, when zooming out. How hard would it be to merge nearby polygons on wider zoom levels? It would not work I think. What would be needed is to generalise polygons on lower zoom levels. Meaning merge them together, drop holes, straighten them (well the dp-filter already takes care of that), and have a seperate style-file where there are definitions on what gets merged how. In general I think this should be solvable. It will be not an easy task and maybe resource hungry, but I think, this should be possible. The subject was discussed already in January 2010 in a side thread of 'Suggestion - Make Douglas Peucker Algorithm more Configurable' Ideally a hole or scrub part of a forest would be only visible from resolution 24-22 or 24-21 (depending on the size of the whole/scrub). It's the same as you only want to see single houses when zoomed in close, when further away you want to see residential area, and when even further away you want to sea where is urban vs nonurban area. Yes, this would be nice. OSM sucks big in this regard and as long raster maps are the primary outcome of OSM data (for lower zooms) then there will be no motivation for change (change which means layering OSM data instead of one big black hole to sink information into). OSM is not a perfect world for cartogaphs. But we have to take it as it is. And it is a database which shows a more or less detailes map at *one* zoom level, the nearest one. I wouldn't like it to include the same information in several zoom levels which have to be held consistent by the users. This will not work. This is a task which *must* be done by algorithms. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
On Wed, Mar 02, Felix Hartmann wrote: 1. If you have this error, please also check if link-pois-to-ways switch was used. According to a post here: http://forum.openstreetmap.org/viewtopic.php?pid=146242#p146242 the address search breaks down on Oregon once --link-pois-to-ways is used. Removing --link-pois-to-ways doesn't make a difference. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] maps with diacritic symbols
hi. i'm terribly sorry if this is a silly question, but i've searched asked around, but so far - failed to solve the problem. i'm trying to generate maps for garmin etrex vista hcx that would contain entities with diacritic symbols (more specifically, map of latvia). i've tried specifying several charsets (utf-8, iso-8859-13, cp-1257 and latin1), but with all of them symbols come out not as expected. with utf-8, cp- and iso- they are garbled in different ways, with latin1 they seem to be transcoded to basic characters. i tried mkgmap 1625 and 1846. any hints on how could i get a map on that device with proper diacritic characters ? ideally utf-8, as i might put maps crossing country borders on it, but at least latvian chars would be enough for the start :) while i'm here, i also tried lowercase option - it mostly worked except for labels on roads where all lowercase symbols seemed to be replaced by underscores. is that something that can be improved with mkgmap, or is it a quirk of the garmin device ? thanks in advance. -- Rich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Include the following patches into trunk -- Patch4 - decrease douglas peucker error
Okay I've done some comparisons between the two approximations. For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex). Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest? Thanks for intensively testing my old patches and the propose for them being checked in. Glad to see them work fine and beeing useful. :-) I have looked at this patch again. I think your proposal of switching between them at a given resolution is a good one. This should preserve the accuracy at higher zooms and compress the data at lower zooms. Should be worth a try. I'm sorry, but at the moment I have no toolchain ready for compiling mkgmap and preparing patches. If I find the time, I will look into it the next days. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] maps with diacritic symbols
while i'm here, i also tried lowercase option - it mostly worked except for labels on roads where all lowercase symbols seemed to be replaced by underscores. is that something that can be improved with mkgmap, or is it a quirk of the garmin device ? Most Garmin units cannot display rotated lowercase letters. If the letters are drawn exact horizontal, e.g. for city names, they work, but all rotated lowercase letters are not displayed. This is not caused by mkgmap but by the device. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
On Wed, Mar 02, Thorsten Kukuk wrote: On Wed, Mar 02, Steve Ratcliffe wrote: So could people confirm that when they see crashes they are not installing via mapsource, and what GPS device they are using? Yes, I'm not installing via mapsource, but copy the gmapsupp.img file directly to the device. It's a GPSmap 62s. I can try the 60CSx tonight, too, haven't done yet. The 60CSx does not crash, only the 62s. But while it finds all Citys, it doesn't find any address or street. Looks like instead of crashing it ignores the data completly. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Countries issues
Thanks for the very specific examples, it should be easy to track down from
them.
I'm on a train at the moment, but my initial guess is that regionOffset in
LocatorConfig should be set. But there must be more to it than that.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I looked a little bit more into it by adding debug info in Locator.java
(see attached patch). I tried different values of location-autofill (-1
thru 4) and it did not change anything.
At that point everything looks fine. Where else could the problem happen?
2011/03/02 16:15:09 FINE (Locator): C:\OSM\maps\Test.osm: Processing
Ackworth
2011/03/02 16:15:09 FINE (Locator): C:\OSM\maps\Test.osm:
is_in=WARREN,IOWA,IOWA,IA,USA
2011/03/02 16:15:09 FINE (Locator): C:\OSM\maps\Test.osm: using format 3
2011/03/02 16:15:09 FINE (Locator): C:\OSM\maps\Test.osm: region:
IOWA, country: UNITED STATES
2011/03/02 16:15:09 FINE (Locator): C:\OSM\maps\Test.osm: region:
IOWA, country: UNITED STATES
Index: src/uk/me/parabola/mkgmap/build/Locator.java
===
--- src/uk/me/parabola/mkgmap/build/Locator.java(revision 1877)
+++ src/uk/me/parabola/mkgmap/build/Locator.java(working copy)
@@ -55,11 +55,13 @@
import java.util.Collection;
import java.util.List;
+import uk.me.parabola.log.Logger;
import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapPointFastFindMap;
import uk.me.parabola.mkgmap.general.MapPointMultiMap;
public class Locator {
+ private static final Logger log = Logger.getLogger(Locator.class);
private final MapPointFastFindMap cityMap
= new MapPointFastFindMap();
private final MapPointMultiMap fuzzyCityMap
= new MapPointMultiMap();
@@ -73,6 +75,8 @@
public void addLocation(MapPoint p)
{
+ log.debug(Processing +p.getName());
+
resolveIsInInfo(p); // Pre-process the is_in field
if(autoFillLevel 1 p.getCity() == null)
@@ -80,7 +84,7 @@
// Without auto-fill city name is the name of the tag
p.setCity(p.getName());
}
-
+
if(p.getCity() != null)
{
cityMap.put(p.getCity(), p);
@@ -96,6 +100,7 @@
placesMap.add(p);
}
+ log.debug( region: + p.getRegion() + , country: +
p.getCountry());
}
@@ -162,7 +167,7 @@
{
String[] cityList = p.getIsIn().split(,);
- //System.out.println(p.getIsIn());
+ log.debug( is_in= + p.getIsIn());
// is_in content is not well defined so we try our best
to get some info out of it
// Format 1 popular in Germany:
County,State,Country,Continent
@@ -179,6 +184,7 @@
if(cityList.length offset)
p.setRegion(cityList[cityList.length-(offset+1)].trim());
+ log.debug( using format 1 );
}
// Format 2 other way round:
Continent,Country,State,County
@@ -192,9 +198,11 @@
if(cityList.length offset)
p.setRegion(cityList[offset].trim());
+
+ log.debug( using format 2 );
}
- // Format like this County,State,Country
+ // Format 3 like this County,State,Country
if(p.getCountry() == null cityList.length 0)
{
@@ -211,6 +219,8 @@
if(cityList.length offset)
p.setRegion(cityList[cityList.length-(offset+1)].trim());
}
+
+ log.debug( using format 3 );
}
}
@@ -222,6 +232,8 @@
if(!isOpenGeoDBCountry(p.getCountry()))
p.setCity(p.getName());
}
+
+ log.debug( region: + p.getRegion() + , country: +
p.getCountry());
}
public MapPoint findNextPoint(MapPoint p)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Splitter hangs when processing pbf with 1 thread only
When processing pbf file with splitter on single processor computer,
processing never finishes. If my guess is correct, the problem is in the
endMap function of the SplitProcessor class. Process hangs on line 176
because of blocking of the toProcess queue. The queue is not processed with
the inner OSMWriterWorker class.
Proposed solution which works for me is (patched to current trunk, i.e. rev.
167):
Index: SplitProcessor.java
--- SplitProcessor.java Base (BASE)
+++ SplitProcessor.java Locally Modified (Based On LOCAL)
@@ -172,7 +172,7 @@
}
}
try {
- toProcess.put(STOP_MSG);// Magic flag used to indicate that all data is
done.
\ No newline at end of file
+ if (maxThreads 1) toProcess.put(STOP_MSG);// Magic flag used to
indicate that all data is done.
\ No newline at end of file
} catch (InterruptedException e1) {
e1.printStackTrace();
Frank
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recent crashes when searching on device
On 02.03.2011 21:29, Thorsten Kukuk wrote: On Wed, Mar 02, Thorsten Kukuk wrote: On Wed, Mar 02, Steve Ratcliffe wrote: So could people confirm that when they see crashes they are not installing via mapsource, and what GPS device they are using? Yes, I'm not installing via mapsource, but copy the gmapsupp.img file directly to the device. It's a GPSmap 62s. I can try the 60CSx tonight, too, haven't done yet. The 60CSx does not crash, only the 62s. But while it finds all Citys, it doesn't find any address or street. Looks like instead of crashing it ignores the data completly. Well that is 100% expected behaviour. Address search only works when sending with Mapsource. Thorsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Problems with latest splitter versions
Hi, I am getting the splitter from svn, compiling and running it unter Windows XP SP3 using JDK 1.6.0_25. There are 2 problems if I am using a splitter version newer than r161 (tryed until r167 so far). 1.) germany.osm.pbf from geofabrik cannot be split -- Invoking the splitter with java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=120 --max-areas=50 --geonames-file=cities1000.zip germany.osm.pbf The data is split into 76 areas, so there are 2 passes to go. First, everything looks fine, but then, at the and of the first pass, the splitter falls asleep, the CPU load for the corresponding JVM drops to 0% and there ist no further progress (except the memory stats being printed periodically). The output looks like this (cut a lot of lines): cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=120 max-threads=1 (auto) mixed=false no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 17:11:11 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing germany.osm.pbf Bounding box 5.864417 47.26543 15.0507701 55.14777 10.000.000 nodes processed... id=283576079 20.000.000 nodes processed... id=355168786 30.000.000 nodes processed... id=495365986 40.000.000 nodes processed... id=699656373 50.000.000 nodes processed... id=998291790 60.000.000 nodes processed... id=1127935431 1.000.000 ways processed... id=25049151 2.000.000 ways processed... id=28822644 Elapsed time: 1m 59s Memory: Current 247MB (20MB used, 227MB free) Max 1484MB 3.000.000 ways processed... id=34073254 4.000.000 ways processed... id=40593158 5.000.000 ways processed... id=49931588 6.000.000 ways processed... id=61188933 7.000.000 ways processed... id=83211109 8.000.000 ways processed... id=93106763 9.000.000 ways processed... id=101081600 100.000 ways processed... id=1124462 in 1 file Time: Wed Mar 02 17:14:00 CET 2011 Exact map coverage is (47.26541519165039,5.864403247833252) to (55.147762298583984,15.05077600479126) Trimmed and rounded map coverage is (47.28515625,5.8447265625) to (55.1513671875,15.029296875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,7.470703125) to (47.9443359375,8.7451171875) contains 663.137 nodes. DONE! [...] Area (53.8330078125,11.77734375) to (54.931640625,14.2822265625) contains 996.051 nodes. DONE! 76 areas: Area 63240001 covers (0x246800,0x4b000) to (0x24d800,0x4f800) DE-Dusseldorf [...] Area 63240076 covers (0x223000,0x63800) to (0x228800,0x7) DE-Reutlingen Writing out split osm files Wed Mar 02 17:14:03 CET 2011 Processing 76 areas in 2 passes, 38 areas at a time Starting pass 1 of 2, processing 38 areas (63240001 to 63240038) Making SparseMultiMap Making SparseMultiMap Processing germany.osm.pbf Bounding box 5.864417 47.26543 15.0507701 55.14777 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap MAP occupancy: 832878 MAP occupancy: 158237 MAP occupancy: 8339 MAP occupancy: 546 MAP occupancy: 1652236 MAP occupancy: 326019 MAP occupancy: 19669 MAP occupancy: 2076 MAP occupancy: 2474023 MAP occupancy: 491531 MAP occupancy: 31585 MAP occupancy: 2861 MAP occupancy: 3272326 MAP occupancy: 668457 MAP occupancy: 53049 MAP occupancy: 6168 Elapsed time: 3m 59s Memory: Current 267MB (121MB used, 146MB free) Max 1484MB MAP occupancy: 4072409 MAP occupancy: 847909 MAP occupancy: 73212 MAP occupancy: 6470 MAP occupancy: 4870695 MAP occupancy: 1026785 MAP occupancy: 94770 MAP occupancy: 7750 MAP occupancy: 5673776 MAP occupancy: 1203597 MAP occupancy: 111531 MAP occupancy: 11096 10.000.000 nodes processed... id=283576079 [...] 60.000.000 nodes processed... id=1127935431 MAP occupancy: 37091591 MAP occupancy: 8145968 MAP occupancy: 704292 MAP occupancy: 58149 MAP occupancy: 37918126 MAP occupancy: 8301600 MAP occupancy: 722028 MAP occupancy: 58246 MAP occupancy: 38711472 MAP occupancy: 8485566 MAP occupancy: 744601 MAP occupancy: 58361 Writing ways Wed Mar 02 17:26:02 CET 2011 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap 1.000.000 ways processed... id=25049151 MAP occupancy: 798645 MAP occupancy: 184591 MAP occupancy: 15271 MAP occupancy: 1493 Elapsed time: 15m 59s Memory: Current 1484MB (705MB used, 779MB free) Max 1484MB 2.000.000 ways processed... id=28822644 [...] 7.000.000 ways processed... id=83211109 Elapsed time: 20m 2s Memory: Current 1484MB (928MB used, 556MB free) Max 1484MB MAP occupancy: 4795349 MAP occupancy: 1103602 MAP occupancy: 94312 MAP occupancy: 6736 MAP occupancy: 1 8.000.000 ways processed... id=93106763 9.000.000 ways processed... id=101081600 MAP occupancy: 5597978 MAP occupancy: 1283033
Re: [mkgmap-dev] Include the following patches into trunk -- Patch4 - decrease douglas peucker error
On 02.03.2011 20:54, Johann Gail wrote: Okay I've done some comparisons between the two approximations. For polygons the old version is much better because the patched version creates bad artifacts. For streets at resolution 23 (if used) to 21 I prefer it too. At resolution 20 I am indifferent and cannot really decide what is better. However from 19 to x the approach as given by the patch is far superior (drawing speed on GPS much higher, actually using the normal DP filter maps become more or less unusable for resolution 16,18 or 19 on etrex). Can someone see how this behaviour could be implemented for lines only from resolution 20 or 19 downwards, while keeping the current approach of the DP filter for the rest? Thanks for intensively testing my old patches and the propose for them being checked in. Glad to see them work fine and beeing useful. :-) I have looked at this patch again. I think your proposal of switching between them at a given resolution is a good one. This should preserve the accuracy at higher zooms and compress the data at lower zooms. Should be worth a try. I'm sorry, but at the moment I have no toolchain ready for compiling mkgmap and preparing patches. If I find the time, I will look into it the next days. Okay great. Hope it's not too difficult to change the behaviour to get the best of both. I think actually at resolution 20, the straight patched behaviour should already be used for all lines. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with latest splitter versions
Le 03/03/2011 00:36, Michael Prinzing a écrit : Hi, 1.) germany.osm.pbf from geofabrik cannot be split -- MAP occupancy: 1 Elapsed time: 22m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 24m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 26m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 28m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 30m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB At this point, nothing more happens, no second pass is done. Any ideas what is going wrong there? Anything I could try? I reported two days ago exactly the same problem to Steve. I sent him yesterday some debug info. Francois -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
