[mkgmap-dev] URLs on https://www.mkgmap.org.uk/download/mkgmap.html needs adjustement
Hi, can whoever has access to the html code change the URLs for the bounds-latest.zip and sea-latest.zip on https://www.mkgmap.org.uk/download/mkgmap.html? google chrome makes quite some problems with the http redirects, while it works fine with firefox. The URLs which should be used are: https://www.thkukuk.de/osm/data/bounds-latest.zip https://www.thkukuk.de/osm/data/sea-latest.zip Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] index option
Hi, On Sat, Nov 13, 7770 wrote: > Hi. > I treid renaming, but it did not help. Like somebody mentioned, it seems to > be > something that Garmin changed in the search alogorythm. Perhaps not much that > one can do to when generating the map. I see the same with old and new GPSmap devices. On old devices (which are really slow compared with new devices), searching for POI is really fast. On new devices, the search is slow and get's slower with every additional installed map, even if this is disabled. But what is also visible: on the old device, what was found is limited, on new devices everything is found. Some people playing with modified indexes came to the conclusion, that it looks like old devices uses the index of a map to search for POI, while new devices go through the data of all installed maps. So depending on the number of POI your map have, the search is slower or faster. Thorsten > Thanks anyhow! > > Karl > > > On torsdag 11 november 2021 19:43:47 CET Gerd Petermann wrote: > > Hi Karl, > > > > I've seen this problem on my Oregon when another map was installed (but not > > activated). The map was the Bicycling-Layer for Europe from > > http://osm.thkukuk.de/ I did not find out why it caused problems, but after > > renaming the corresponding *.img file the search was fast again. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag von 7770 > > <7...@foskan.eu> Gesendet: Donnerstag, 11. November 2021 19:22 > > An: mkgmap-dev@lists.mkgmap.org.uk > > Betreff: [mkgmap-dev] index option > > > > Hi. > > > > I generate maps using the following options (among others) > > --net --route --index --split-name-index > > > > When loading the ready img file to a GPSMAP 66st it is very slow in > > searching for cities (FIND -> Cities). Searching for some location can take > > many minutes or even lock the unit in rare cases. > > The problem is present even if a specific map is selected and search is only > > conducted within that map. > > > > Loading the same img file on an old etrex vista hcx did show very fast city > > search. > > > > Does anyone know if the options given to mkgmap can impact negatively in > > this particular scenaio or if there can be some other option added to make > > city search faster? > > > > Side note: street name search is fast, but searching among All POIs is also > > slow. > > > > Regards > > Karl > > > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with SeaGenerator
Hi Gerd, On Thu, Oct 14, Gerd Petermann wrote: > Hi Thorsten, > > new test with r4808 against latest land-polygons-split-4326 from today found > no problems. > Maybe use the downloaded shapes for now until you found out what's wrong? The UK coastline was broken (high of London). I assume land-polygons-split-4326 was build with automatic closing of rings. I restored the coastline now in the OSM data. Thorsten > Gerd > > > Von: mkgmap-dev im Auftrag von Gerd > Petermann > Gesendet: Donnerstag, 14. Oktober 2021 17:51 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problems with SeaGenerator > > Hi again, > sorry, I tested with old shapes from 2014. Have to redo my tests... > > Gerd > > > Von: Gerd Petermann > Gesendet: Donnerstag, 14. Oktober 2021 17:49 > An: Development list for mkgmap > Betreff: AW: [mkgmap-dev] Problems with SeaGenerator > > Hi Thorsten, > > I reverted to r4689 and got similar results for the data, so I'd say it is > likely that the shape data is wrong. If there are really no problems in the > coastline data there may be a problem in the process that calculates the > shapes. > > Gerd > > > Von: mkgmap-dev im Auftrag von Gerd > Petermann > Gesendet: Donnerstag, 14. Oktober 2021 17:15 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Problems with SeaGenerator > > Hi Thorsten, > > okay, I see error messages for the downloaded shapes: > Generation took 620720 ms > Preforming quick check against reference for index file. > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 60.820313,31.289063, index key is 2818048_1441792 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 60.820313,31.992188, index key is 2818048_1474560 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 48.164063,-87.539063, index key is 2228224_-4096000 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 48.164063,-86.835938, index key is 2228224_-4063232 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 47.460938,-89.648438, index key is 2195456_-4194304 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 47.460938,-86.835938, index key is 2195456_-4063232 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 47.460938,-86.132813, index key is 2195456_-4030464 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 47.460938,-85.429688, index key is 2195456_-3997696 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 44.648438,-82.617188, index key is 2064384_-3866624 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, land-only > tile is flooded around 42.539063,-86.835938, index key is 1966080_-4063232 > SCHWERWIEGEND (SeaGenerator): Precomp sea data seems to be wrong, sea-only > tile is now land around -35.507813,-56.601563, index key is -1671168_-2654208 > Precomp sea data seems to be wrong. Use option --x-check-precomp-sea=0 to > continue risking bad sea data. > Please don't publish this data > > I'll try to find out if a recent change in mkgmap causes this. > Gerd > > > Von: mkgmap-dev im Auftrag von > Thorsten Kukuk > Gesendet: Donnerstag, 14. Oktober 2021 17:11 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Problems with SeaGenerator > > On Thu, Oct 14, Gerd Petermann wrote: > > > Hi Thorsten, > > > > did not see a warning for tile 2654208_-163840 in my quick check, running > > full creation now. > > Seems the shapes were refreshed today. The README says: > > Date of the data used is 2021-10-14T00:00:00Z > > > > Did you use that as input or an older version? > > I use the OSM data from today (2021-10-14, 01:53 CEST) > and build my own shapes from it. > > Thorsten > > > Gerd > > > > > > Von: Gerd Petermann > > Gesendet: Donnerstag, 14. Oktober 2021 16:39 > > An: Development list for mkgmap > > Betreff: AW: [mkgmap-dev] Problems with SeaGenerator > > > > Hi Thorsten, > > > > seems you missed the changes in r4689? > > See https://www.mkgmap.org.uk/websvn/revision.p
Re: [mkgmap-dev] Problems with SeaGenerator
On Thu, Oct 14, Gerd Petermann wrote: > Hi Thorsten, > > did not see a warning for tile 2654208_-163840 in my quick check, running > full creation now. > Seems the shapes were refreshed today. The README says: > Date of the data used is 2021-10-14T00:00:00Z > > Did you use that as input or an older version? I use the OSM data from today (2021-10-14, 01:53 CEST) and build my own shapes from it. Thorsten > Gerd > > > Von: Gerd Petermann > Gesendet: Donnerstag, 14. Oktober 2021 16:39 > An: Development list for mkgmap > Betreff: AW: [mkgmap-dev] Problems with SeaGenerator > > Hi Thorsten, > > seems you missed the changes in r4689? > See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4689 > > reg. compile: I think these hints are still correct: > https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompiled_sea_yourself > > I use open jdk (from AdoptOpenJDK) to build. openjdk version "1.8.0_272" and > mkgmap works fine with it. > > I'll try to download latest data from > https://osmdata.openstreetmap.de/data/land-polygons.html to check if the > index file > sea-check.txt needs to be changed or what else is wrong. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Thorsten Kukuk > Gesendet: Donnerstag, 14. Oktober 2021 16:26 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Problems with SeaGenerator > > > Hi, > > Some users reported problems with my sea data, they get error messages > since about a week like: > Precomp sea data seems to be wrong, land-only tile is flooded around > 57.304688,-3.164063, index key is 2654208_-163840 > > All coordinates are in Great Britain, and this error and build aborts > also happens if the data they try to compile is far outside the UK and > does not contain it. > > Since I don't get that with my one year old mkgmap version, I run into > the first challange: building the current mkgmap version with SeaGenerator > enabled... > Is there any chance to update mkgmap and all dependencies to use a newer > java version? > I need openjdk-1.8 to build mkgmap and Oracle jre-1.8 to run it... > mkgmap will not work with openjdk-1.8 and it looks like Oracle does not > really provide a jdk-1.8 anymore... > > Now with mkgmap r4808 I get the same errors already when generating the > precomp sea data. But I cannot find any problems with tje OSM data: no > coastline checker reports any problems in the UK area... > > Any idea how to solve this correct? > > Thanks, > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with SeaGenerator
Hi Gerd, On Thu, Oct 14, Gerd Petermann wrote: > Hi Thorsten, > > seems you missed the changes in r4689? > See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4689 I either I missed oder I forgot that, as it did not create problems until yet... And it looks like you cannot disable the check if you build the precomp sea data... > reg. compile: I think these hints are still correct: > https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompiled_sea_yourself That's what I'm always doing. > I use open jdk (from AdoptOpenJDK) to build. openjdk version "1.8.0_272" and > mkgmap works fine with it. I used our own openjdk-1.8.0.302 this morning, but the error is not new, I was never able to build a map successfull with openjdk. Most of the time you get errors in some Sun classes, but I don't remember the exact error messages anymore. So I need openjdk-1.8 to build mkgmap, Oracle/Sun jre-1.8 to build the maps and openjdk >= 11 to run josm and other java tools. It's getting complicated ;) > I'll try to download latest data from > https://osmdata.openstreetmap.de/data/land-polygons.html to check if the > index file > sea-check.txt needs to be changed or what else is wrong. I did build now a map of the UK and UK is flooded (but not Ireland or the rest of Europe). So if mkgmap doesn't do something wrong there is a problem with the OSM data the coastline checkers haven't found yet... Thorsten > ____ > Von: mkgmap-dev im Auftrag von > Thorsten Kukuk > Gesendet: Donnerstag, 14. Oktober 2021 16:26 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Problems with SeaGenerator > > > Hi, > > Some users reported problems with my sea data, they get error messages > since about a week like: > Precomp sea data seems to be wrong, land-only tile is flooded around > 57.304688,-3.164063, index key is 2654208_-163840 > > All coordinates are in Great Britain, and this error and build aborts > also happens if the data they try to compile is far outside the UK and > does not contain it. > > Since I don't get that with my one year old mkgmap version, I run into > the first challange: building the current mkgmap version with SeaGenerator > enabled... > Is there any chance to update mkgmap and all dependencies to use a newer > java version? > I need openjdk-1.8 to build mkgmap and Oracle jre-1.8 to run it... > mkgmap will not work with openjdk-1.8 and it looks like Oracle does not > really provide a jdk-1.8 anymore... > > Now with mkgmap r4808 I get the same errors already when generating the > precomp sea data. But I cannot find any problems with tje OSM data: no > coastline checker reports any problems in the UK area... > > Any idea how to solve this correct? > > Thanks, > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Problems with SeaGenerator
Hi, Some users reported problems with my sea data, they get error messages since about a week like: Precomp sea data seems to be wrong, land-only tile is flooded around 57.304688,-3.164063, index key is 2654208_-163840 All coordinates are in Great Britain, and this error and build aborts also happens if the data they try to compile is far outside the UK and does not contain it. Since I don't get that with my one year old mkgmap version, I run into the first challange: building the current mkgmap version with SeaGenerator enabled... Is there any chance to update mkgmap and all dependencies to use a newer java version? I need openjdk-1.8 to build mkgmap and Oracle jre-1.8 to run it... mkgmap will not work with openjdk-1.8 and it looks like Oracle does not really provide a jdk-1.8 anymore... Now with mkgmap r4808 I get the same errors already when generating the precomp sea data. But I cannot find any problems with tje OSM data: no coastline checker reports any problems in the UK area... Any idea how to solve this correct? Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Blue background with Oregons, what whas the solution?
On Thu, Apr 02, Thorsten Kukuk wrote: > On some Garmin devices (newer Oregons, e.g.) parts of the background > of the map is shown as blue "sea", not with the normal background. > Does anybody remember what the problem was and how to fix that? > Since I don't own any of this devices who show it "wrong", I cannot test > it myself. Sorry for the later response, but it took some time until I got feedback from the reporters of the problem about my changes to fix it. The reason is: with very old Garmin devices, you should not modify the background as this could have lead to problems. With some new devices, you have to modify the background, means you need a polygone 0x04b with draworder 1, and only this polygone with this draw order. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Blue background with Oregons, what whas the solution?
Hi, I'm pretty sure that I did read the discussion here, but cannot find it anywhere again. On some Garmin devices (newer Oregons, e.g.) parts of the background of the map is shown as blue "sea", not with the normal background. Does anybody remember what the problem was and how to fix that? Since I don't own any of this devices who show it "wrong", I cannot test it myself. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter, mapid
Hi, On Mon, Dec 17, Gerd Petermann wrote: > Hi all, > > I've never tried it, but my understanding was that you can have the same tile > (mapid) in two different gmapsupp files. > E.g. you might create a tile containing an area around Hamburg and put that > tile into a gmapsupp for Germany as well as another > one for Lower Saxony. > If that is right it would explain why you have to make sure that the content > of two tiles with the same id doesn't differ. Correct, this works, but only if the tile is 100% identical for both maps. Or in other words: create a big map and select tiles from this map to build smaller maps. So the same as if you select tiles in mapsource from a bigger map and transfer them to the GPS device. Thorsten > @Brad: I think the current documentation about the meaning of all those names > and ids is not perfect because the authors of mkgmap > were still learning when the docu was created, and it's an ongoing process ;-) > Feel free to improve the docu (post a patch or maybe a new version of one or > more files). > > Gerd > > > Von: mkgmap-dev im Auftrag von brad > > Gesendet: Montag, 17. Dezember 2018 01:47 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] splitter, mapid > > One thing I think I missed, is that each tile on a garmin device needs a > unique mapid. A different family-id and mapname for each gmap is not > sufficient. Does this sound correct? > > I'd been downloading US states from Geofabrik, creating maps with unique > family-id, mapname, every name & id that seemed important, (with > mkgmap) but when I put them on the Garmin they all wouldn't show up. > Only when I went back to the splitter step & used a different mapid did > they all show up. > > Sometimes I'm not too good at reading directions, did I overlook this > someplace? > > Brad > ___ > 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter: option for maximum tile area?
On Thu, Nov 01, Gerd Petermann wrote: > Hi Bernhard, > > my understanding is that you should never see broken precompiled sea data, > because the data source is not directly OSM > but http://openstreetmapdata.com/data/land-polygons where Jochen Topf invests > time to check that the data is OK before updating it. > So, sea.zip might not be up to date but should always be OK. Not really, as he writes on his web page, his tools tries to repair the coastlines. And as I use them, too, I know that this automatic "repair" can break the result even more. I have added some additional post-precessing checks and patched osmcoastline to bail out on more errors to make sure that the result is for me really useable. Currently the coastlines are so heavy broken, that osmcoastline only seg.faults. So there will be no update with the broken costlines. I assume that why geofabrik does not report coastlines errors anymore, too. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DEM and SRTM hgt files: size too small
On Thu, Nov 01, Bernhard Hiller wrote: > Hi Thorsten, > viewfinderpanoramas provides files for that area too. Download cells M32 and > M33 from > http://www.viewfinderpanoramas.org/Coverage map viewfinderpanoramas_org3.htm > The unzipped files all have a size of 2818 kb, and work well with mkgmap. That's the 3" tiles, I hoped I could re-use the SRTM1v3 data so that I don't need to store everything twice. Wondering myself, why even the geotiff SRTM1v3 tiles for this area have only half of the size then other tiles have. Looks like I need to dig deeper into gdal. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] DEM and SRTM hgt files: size too small
Hi, I started to play with maps with DEM, but run into a problem: viewfinderpanoramas.org provides hgt files, but only for some areas. The SRTM1v3.0 data is using geotiff. No problem, you can convert them with gdal_translate and fill the missing areas. Works fine for below N50, but starting with N50, the data is much smaller and this leads to the following error: SEVERE (HGTReader): 71200154.osm.pbf: file /data/OSM/data/hgt/N50E012.hgt has unexpected size 12970802 and is ignored SEVERE (HGTReader): 71200154.osm.pbf: file /data/OSM/data/hgt/N50E013.hgt has unexpected size 12970802 and is ignored SEVERE (HGTReader): 71200159.osm.pbf: file /data/OSM/data/hgt/N50E014.hgt has unexpected size 12970802 and is ignored Any ideas how to solve the problem? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter: "Cannot store node id 9223372036854775807, this value is reserved"
On Mon, Oct 29, Bernhard Hiller wrote: > Hi Gerd, > I am investigation the origin of that id. > I tried to run splitter on the file generated by srtm2osm. Try phyghtmap. In my experience, that works much better than srtm2osm. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Download for sea.zip
On Fri, Oct 26, Bernd Weigelt wrote: > This is my command line > > bernd@apoll:~> java -Xmx6800m -cp ~/temp/test/mkgmap.jar;~/temp/test/lib/ > optional/* uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator ~/ > map_build/test/land-polygons-split-4326/land_polygons.shp WGS84 ~/temp/test Syntax error: ";" must be ":" on Linux. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Download for sea.zip
On Thu, Oct 25, Bernd Weigelt wrote: > Hi Thorsten > > Is it possible to write a short description, what you have done to make that > work? bounds.zip or sea.zip? My bounds always worked, sea.zip only works with java 1.8 as Gerd descriped, additional my java 1.8 installation was broken, re-install fixed that. Thorsten > Thx > > Bernd > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. > > Am 25. Oktober 2018 15:18:35 MESZ schrieb Thorsten Kukuk : > >On Thu, Oct 25, Steph Ixus wrote: > > > >> Hi, > >> > >> I've uploaded a sea.zip in my Dropbox. > >> > >> https://www.dropbox.com/s/vj65yv1a9yv9s7i/sea-24oct.18.zip?dl=0 > >> > >> Thank you Thorsten for the scripts :-) > > > >bounds*-zip and sea-*.zip can also be found on my page: > >http://osm.thkukuk.de/data/ > > > >The bounds are current, sea-*.zip should be updated the next days > >after I fixed now my java issues with mkgmap SeaGenerator. > >Now somebody only needs to fix the coastline in the OSM data ;), > >somebody broke that terrible yesterday :(. > > > > Thorsten > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Download for sea.zip
On Fri, Oct 26, Gerd Petermann wrote: > Hi Thorsten, > > would it be okay if I change the links on the mkgmap download page to your > site? > I've just learned that I can do that. Fine with me, I don't think that I will get any traffic problems. Else I will speak up. Thorsten > Gerd > > > Von: mkgmap-dev im Auftrag von > Thorsten Kukuk > Gesendet: Donnerstag, 25. Oktober 2018 15:18 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Download for sea.zip > > On Thu, Oct 25, Steph Ixus wrote: > > > Hi, > > > > I've uploaded a sea.zip in my Dropbox. > > > > https://www.dropbox.com/s/vj65yv1a9yv9s7i/sea-24oct.18.zip?dl=0 > > > > Thank you Thorsten for the scripts :-) > > bounds*-zip and sea-*.zip can also be found on my page: > http://osm.thkukuk.de/data/ > > The bounds are current, sea-*.zip should be updated the next days > after I fixed now my java issues with mkgmap SeaGenerator. > Now somebody only needs to fix the coastline in the OSM data ;), > somebody broke that terrible yesterday :(. > > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) > ___ > 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Download for sea.zip
On Thu, Oct 25, Steph Ixus wrote: > Hi, > > I've uploaded a sea.zip in my Dropbox. > > https://www.dropbox.com/s/vj65yv1a9yv9s7i/sea-24oct.18.zip?dl=0 > > Thank you Thorsten for the scripts :-) bounds*-zip and sea-*.zip can also be found on my page: http://osm.thkukuk.de/data/ The bounds are current, sea-*.zip should be updated the next days after I fixed now my java issues with mkgmap SeaGenerator. Now somebody only needs to fix the coastline in the OSM data ;), somebody broke that terrible yesterday :(. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] PrecompSeaGenerator - which geotools version?
On Tue, Oct 23, Gerd Petermann wrote: > Hi Thorsten, > > do you execute with the libs downloaded with the build file? > They are in lib/optional and should be quite old. Yes, that's the one I used this time. And that's why I wrote the initial first mail of this thread: new versions bring other errors and I haven't found yet a version which works. Thorsten > Gerd > > > Von: mkgmap-dev im Auftrag von > Thorsten Kukuk > Gesendet: Dienstag, 23. Oktober 2018 15:08 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] PrecompSeaGenerator - which geotools version? > > > Hi Gerd, > > On Sat, Oct 20, Gerd Petermann wrote: > > > Hi Thorsten, > > > > my steps to compile from scratch: > > 1) svn checkout > > 2) edit build.xml and remove the line > > > > 3) execute ant resolve-optional dist > > This compiles, but gives me: > Exception in thread "main" java.lang.IllegalArgumentException: > org.geotools.data.DataStoreFactorySpi is not an ImageIO SPI class > at > java.desktop/javax.imageio.spi.ServiceRegistry.checkClassAllowed(ServiceRegistry.java:722) > at > java.desktop/javax.imageio.spi.ServiceRegistry.(ServiceRegistry.java:117) > at > org.geotools.factory.FactoryRegistry.(FactoryRegistry.java:154) > at org.geotools.factory.FactoryCreator.(FactoryCreator.java:90) > at > org.geotools.data.DataStoreFinder.getServiceRegistry(DataStoreFinder.java:126) > at > org.geotools.data.DataStoreFinder.getAvailableDataStores(DataStoreFinder.java:114) > at > org.geotools.data.DataStoreFinder.getDataStore(DataStoreFinder.java:86) > at > uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.createShapefileAccess(PrecompSeaGenerator.java:241) > at > uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.runSeaGeneration(PrecompSeaGenerator.java:259) > at > uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.main(PrecompSeaGenerator.java:414) > > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) > ___ > 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] PrecompSeaGenerator - which geotools version?
Hi Gerd, On Sat, Oct 20, Gerd Petermann wrote: > Hi Thorsten, > > my steps to compile from scratch: > 1) svn checkout > 2) edit build.xml and remove the line > > 3) execute ant resolve-optional dist This compiles, but gives me: Exception in thread "main" java.lang.IllegalArgumentException: org.geotools.data.DataStoreFactorySpi is not an ImageIO SPI class at java.desktop/javax.imageio.spi.ServiceRegistry.checkClassAllowed(ServiceRegistry.java:722) at java.desktop/javax.imageio.spi.ServiceRegistry.(ServiceRegistry.java:117) at org.geotools.factory.FactoryRegistry.(FactoryRegistry.java:154) at org.geotools.factory.FactoryCreator.(FactoryCreator.java:90) at org.geotools.data.DataStoreFinder.getServiceRegistry(DataStoreFinder.java:126) at org.geotools.data.DataStoreFinder.getAvailableDataStores(DataStoreFinder.java:114) at org.geotools.data.DataStoreFinder.getDataStore(DataStoreFinder.java:86) at uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.createShapefileAccess(PrecompSeaGenerator.java:241) at uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.runSeaGeneration(PrecompSeaGenerator.java:259) at uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.main(PrecompSeaGenerator.java:414) Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] PrecompSeaGenerator - which geotools version?
Hi, I tried to update my build environment for OSM maps, but with current mkgmap versions, I have some problems to get the SeaGenerator working together with geotools. Neither the old one I used until now with an older mkgmap version, nor newer ones seem to work. With 19.3 I get the following error: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.geotools.resources.NIOUtilities (file:/usr/share/java/mkgmap-SeaGenerator/gt-metadata.jar) to method java.nio.DirectByteBuffer.cleaner() WARNING: Please consider reporting this to the maintainers of org.geotools.resources.NIOUtilities WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Exception in thread "main" java.lang.NoClassDefFoundError: uk/me/parabola/splitter/OSMWriter at uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.runSeaGeneration(PrecompSeaGenerator.java:274) at uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator.main(PrecompSeaGenerator.java:414) Caused by: java.lang.ClassNotFoundException: uk.me.parabola.splitter.OSMWriter at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:190) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499) Any idea, what goes wrong? What would be the correct splitter version and geotools version for mkgmap-r4245? Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Build PrecompSeaGenerator by default?
On Sun, Oct 14, Gerd Petermann wrote: > Hi Thorsten, > to be honest, I don't know why it is not done. I see no problem to build > mkgmap.jar without the line > > in build.xml. The jar grows by ~ 20 KB, but still works without any of the > optional libs when you use it for the normal purposes. > Maybe some QA tools would complain? The readme.txt says: "The PrecompSeaGenerator is not included in the mkgmap.jar due to additional dependencies." But I don't see it as problem. > If you think about releasing a jar file that also contains all the optional > libs for the PrecompSeaGenerator this would be a bigger change, > the libs are > 20 MB and I fear that the old splitter.jar needed for the > PrecompSeaGenerator might confuse new users. Do you mean with optional libs the "geotools"? I don't think we need to include them. Whoever is using the SeaGenerator, should have enough knowledge to enhance the searchpath with help of the readme.txt from mkgmap. Thorsten > Gerd > > ____ > Von: mkgmap-dev im Auftrag von > Thorsten Kukuk > Gesendet: Sonntag, 14. Oktober 2018 11:51 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Build PrecompSeaGenerator by default? > > > Hi, > > as I build my precompiled sea data myself: can we build the > PrecompSeaGenerator of mkgmap by default with the binary mkgmap jar? > This would allow to use the default mkgmap jar and does not require > to always rebuild it at my own. > > Thanks, > Thorsten > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) > ___ > 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Build PrecompSeaGenerator by default?
Hi, as I build my precompiled sea data myself: can we build the PrecompSeaGenerator of mkgmap by default with the binary mkgmap jar? This would allow to use the default mkgmap jar and does not require to always rebuild it at my own. Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in index
Hi Gerd, On Wed, Jul 11, Gerd Petermann wrote: > I am back from my cycling tour. I've observed a problem with my self compiled > gmapsupp, the device doesn't find most of the restaurant POIs. > Search for e.g. shops or hotels worked fine, just POI with 0x2a?? seem to > cause trouble. Search takes very long and shows only a few far away > restaurants. > I wonder if anybody else has the same problems? Yes, very old problem, and I think already discussed on this list without resolution. Depending on the count of POIs, sometimes parts of them are not findable in the Index, while they are visible on the map. The number of the POI doesn't matter, it looks more like the number of POI. That POI searches take very long is a change in the Garmin firmware. With my map on a GPSmap 60CSx, searching for POI is really quick and only the one from the Index are found. With the same map on my GPSmap 62, the index is ignored and the POIs are extracted from the map. This takes a long time. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] test map
On Wed, May 17, Gerd Petermann wrote: > Hi all, > > I've uploaded a small test map that shows the problem on my Oregon 600 with > firmware 5.00: > http://files.mkgmap.org.uk/download/353/gmapsupp.img > > Please test what your device shows when you search for > a) all roads in city "Albertslund Kommune". On my Oregon the list contains > many entries, esp. these My GPSMap 62S does not have an "all roads" option and does > b) all roads in city "Albertslund Kommune" starting with A. My Oregon shows > only > Abildgården The GPSMap 62S only shows that street, too. > I think It should show the above entries. > c) all roads in city "Albertslund Kommune" starting with Æ. My Oregon says > "No result found" > d)all roads in city "Albertslund Kommune" starting with Ae. My Oregon says > "No result found" For both the same here. > e) all roads in city "Albertslund Kommune" starting with Al. My Oregon shows > Alberts Have > Alberts Vænge > ... more with letters Al > (good) Same here. So the GPSMap 62s behaves the same way as your Oregon. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POI without name
Hi Gerd, On Fri, Apr 28, Gerd Petermann wrote: > Hi Thorsten, > > do you see that behaviour also with original Garmin maps? With original Garmin maps it is much faster. But hard to say if they use the index or look into the tiles: they don't have nearly as many POIs as my OSM maps have. Are there somewhere free Garmin Maps with a lot of POIs for testing? Thorsten > Maybe the device ignores the index if it detects errors in it. > > Gerd > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Thorsten Kukuk <ku...@suse.de> > Gesendet: Freitag, 28. April 2017 10:37:50 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] POI without name > > On Fri, Apr 28, Gerd Petermann wrote: > > > I've noticed that my Oregon shows a lot of "unnamed" attractions, e.g. when > > I search for Attraction | Park or Garden. > > It seems that the device shows all points wth type 0x2c06 here (maybe also > > others), no matter if they are indexed or not, > > if at least one of them is named and therefore indexed, maybe not all but > > those in the same sub division of the map. > > Maybe there is a flag somewhere which would tell the device if that should > > be done or not, but I did not find that yet. > > Any hints are welcome. > > I can only say for the GPSMap 6x series (at least for the three devices > I own): > Old firmwares use the index for POI search. It is quick and you only > see what is in the index. > New firmwares seems to lookup POI directly in the tiles and not use the > Index at all. Even if the device is newer and faster than the old one, > searching POIs with this can take a really long time ... > And in my experiements, all POI will be shown in the index, independent > of the number. At least I haven't found any which is not shown. With > the old firmware, a lot of numbers are not shown in the list. > > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) > ___ > 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POI without name
On Fri, Apr 28, Gerd Petermann wrote: > I've noticed that my Oregon shows a lot of "unnamed" attractions, e.g. when I > search for Attraction | Park or Garden. > It seems that the device shows all points wth type 0x2c06 here (maybe also > others), no matter if they are indexed or not, > if at least one of them is named and therefore indexed, maybe not all but > those in the same sub division of the map. > Maybe there is a flag somewhere which would tell the device if that should be > done or not, but I did not find that yet. > Any hints are welcome. I can only say for the GPSMap 6x series (at least for the three devices I own): Old firmwares use the index for POI search. It is quick and you only see what is in the index. New firmwares seems to lookup POI directly in the tiles and not use the Index at all. Even if the device is newer and faster than the old one, searching POIs with this can take a really long time ... And in my experiements, all POI will be shown in the index, independent of the number. At least I haven't found any which is not shown. With the old firmware, a lot of numbers are not shown in the list. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP decompiler for linux?
On Tue, Mar 14, Harri Suomalainen wrote: > Is there any tool to decompile typ files in Linux (or some online tool) ? I > seem to find only tools that work on windows. Unfortunately I have no > windows machine available. Most of the TYP file editors for Windows work fine with wine on Linux. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NullPointerException with 3736
On Wed, Dec 21, Gerd Petermann wrote: > Hi Thorsten, > > thanks, I was able to reproduce it and I have committed r3739 to fix it. > Sorry for that. Thanks and no problem. Thorsten > Gerd > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Thorsten Kukuk <ku...@suse.de> > Gesendet: Mittwoch, 21. Dezember 2016 15:11:59 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] NullPointerException with 3736 > > On Wed, Dec 21, Gerd Petermann wrote: > > > Hi Thorsten, > > > > please try again with r3738. If you can reproduce the problem I may need > > more info. > > I can still reproduce it. > > I try to build a map from germany/austria/swizerland with my marine style: > > mkgmap --style-file=style --family-name=TK-DACH-Marine --country-name=DACH > --country-abbr=DACH --area-name=DACH --latin1 > --license-file=TK-DACH-Marine_license.txt '--copyright-message=OpenStreetMap > contributors, ODbL. See: http://www.openstreetmap.org/copyright. > TK-DACH-Marine based on data from 2016-12-20.' --series-name=TK-DACH-Marine > --product-version=161221 --add-pois-to-areas > '--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance' > --reduce-point-density=4 --reduce-point-density-polygon=8 > --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 > --make-opposite-cycleways --name-tag-list=name,place_name,loc_name > --transparent --no-poi-address -c mkgmap.cfg --gmapsupp -c maps.cfg > --description=TK-DACH-Marine TK_DACH.TYP > > http://osm.thkukuk.de/tmp/71200019.osm.pbf is the input file where I get > this error. > > Thorsten > > -- > Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CASP > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) > ___ > 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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CASP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NullPointerException with 3736
On Wed, Dec 21, Gerd Petermann wrote: > Hi Thorsten, > > please try again with r3738. If you can reproduce the problem I may need more > info. I can still reproduce it. I try to build a map from germany/austria/swizerland with my marine style: mkgmap --style-file=style --family-name=TK-DACH-Marine --country-name=DACH --country-abbr=DACH --area-name=DACH --latin1 --license-file=TK-DACH-Marine_license.txt '--copyright-message=OpenStreetMap contributors, ODbL. See: http://www.openstreetmap.org/copyright. TK-DACH-Marine based on data from 2016-12-20.' --series-name=TK-DACH-Marine --product-version=161221 --add-pois-to-areas '--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance' --reduce-point-density=4 --reduce-point-density-polygon=8 --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 --make-opposite-cycleways --name-tag-list=name,place_name,loc_name --transparent --no-poi-address -c mkgmap.cfg --gmapsupp -c maps.cfg --description=TK-DACH-Marine TK_DACH.TYP http://osm.thkukuk.de/tmp/71200019.osm.pbf is the input file where I get this error. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CASP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] NullPointerException with 3736
Hi, with mkgmap r3736 I get: java.lang.NullPointerException at uk.me.parabola.mkgmap.build.MapArea.split(MapArea.java:241) at uk.me.parabola.mkgmap.build.MapSplitter.splitMaxSize(MapSplitter.java:239) at uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:104) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:696) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:232) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 That map has a lot of empty space and tiles and only a few POI in some of the tiles. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CASP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Roundabout checks
Hi, On Wed, Aug 03, Gerd Petermann wrote: > I've tried to collect special cases reg. this. I've seen places with a road > going straight through a roundabout . > > I assume one is not allowed to enter the roundabout from these roads, but I > don't know how this is > correctly mapped. Do you have an example for this? I know examples, where you have a roundabout and a street going straight forward: cars have to use the roundabout, and trucks and busses are allowed to go straight through the roundabout in special situations. But then there should be access rules for this. Or the mapper forgot the bridge, since the street is going via a bridge above the roundabout. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option to output polygons in size order
On Sun, Jul 31, Gerd Petermann wrote: > The only other input file is the bounds file. I cannot think of a good reason > why that would > change the result unless it is somehow corrupted. The coastlines where several times broken in the last weeks and I saw a flooding of europe. Somebody was so clever to tag buildings with natural=coastline ... But in this case, not only the islands, but the whole land area should be flooded. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option to output polygons in size order
I > >>> do this in a very limited way already - by having some polygons like water > >>> and forest in several versions with different priority based on layer tag > >>> - > >>> this did help a lot) > >>> > >>> Felix > >>> > >>> On 27 July 2016 at 13:41, Gerd Petermann < > >>> gpetermann_muenc...@hotmail.com> wrote: > >>> > >>>> Hi Felix, > >>>> > >>>> > >>>> okay, maybe I'll add this as an experimental option as well. > >>>> > >>>> One big question here is: At what point would the cutting > >>>> > >>>> happen? Before style processing (as we do with mp-relations) > >>>> > >>>> or maybe as a new stage before the img data is written. > >>>> > >>>> > >>>> What I don't yet understand is the idea that a smaller > >>>> > >>>> polygon is more important. Do you have examples for that, > >>>> > >>>> esp. cases where shapes do only partially overlap? > >>>> > >>>> > >>>> Gerd > >>>> -- > >>>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag > >>>> von Felix Hartmann <extremecar...@gmail.com> > >>>> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37 > >>>> *An:* Development list for mkgmap > >>>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order > >>>> > >>>> > >>>> On 27 July 2016 at 09:29, Gerd Petermann < > >>>> gpetermann_muenc...@hotmail.com> wrote: > >>>> > >>>>> reg. the idea of "cutting out overlaps": I guess it would consume > >>>>> quite a lot of CPU and it would heavily increase the img size > >>>>> > >>>>> because we would have to write many more points. Think of a shape for > >>>>> "place=village" with hundreds of holes for each building > >>>>> > >>>>> shape. Up to now we save the shape for the village and the shapes for > >>>>> the buildings. With cutting we have to calculate what > >>>>> > >>>>> remains of the village shape, this would be a very complex shape with > >>>>> many holes, so it would have many points. > >>>>> > >>>>> I don't think that would be a good idea. > >>>>> > >>>>> > >>>> Well that's why I wrote we will need an additional file in the > >>>> style-file for this. So only for certain polygons this should be done. > >>>> Prime examples are: any kind of forest, most kind of water, and maybe a > >>>> handful more. However definitely not buildings or for example poygons you > >>>> can put semi-transparent. > >>>> > >>>> I'm quite sure with this limited approach 90% of problems would be > >>>> gone. And mapsize only a couple percent bigger. However I have no clue > >>>> about complexity and CPU cycles for such a limited approach. > >>>> > >>>> > >>>> -- > >>>> Felix Hartman - Openmtbmap.org & VeloMap.org > >>>> Schusterbergweg 32/8 > >>>> 6020 Innsbruck > >>>> Austria - Österreich > >>>> > >>>> ___ > >>>> mkgmap-dev mailing list > >>>> mkgmap-dev@lists.mkgmap.org.uk > >>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >>>> > >>> > >>> > >>> > >>> -- > >>> Felix Hartman - Openmtbmap.org & VeloMap.org > >>> Schusterbergweg 32/8 > >>> 6020 Innsbruck > >>> Austria - Österreich > >>> > >>> ___ > >>> mkgmap-dev mailing list > >>> mkgmap-dev@lists.mkgmap.org.uk > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > >>> > >> > >> > >> > >> -- > >> Felix Hartman - Openmtbmap.org & VeloMap.org > >> Schusterbergweg 32/8 > >> 6020 Innsbruck > >> Austria - Österreich > >> > > > > > > > > -- > > Felix Hartman - Openmtbmap.org & VeloMap.org > > Schusterbergweg 32/8 > > 6020 Innsbruck > > Austria - Österreich > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > Schusterbergweg 32/8 > 6020 Innsbruck > Austria - Österreich > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Tool to dump index?
Hi, from time to time I face the problem, that POI or addresses are not findable in mapsource or on the GARMIN device. But if you look at the map, they are there. With other styles, or making "small" changes to the style by disabling a random POI, suddenly they are there. But sometimes then other POI or addresses are missing. Is there a tool which dissembles a map and prints relevant informations about the index? I would like to compare the cases, where an index entry is not found and where it is found, and what the difference is. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Roundabouts causes crashing devices
On Fri, Jul 08, Minko wrote: > It happens with recent GPS devices like the Oregon 6xx series, Garmin Edge > Touring and 8xx, GPS map 62 and 64. > It does not happen with older devices. I cannot find any roundabout in my > vicinty to reproduce it so it does not happen all the time with every > firmware. The only thing that all those reports have in common is that it > happens near a roundabout, the device is dying slowly, turning it back on > will make it work again. > > Did anyone here have seen the same behaviour? I have roundabouts nearly at the front of my home, so I'm routing through it nearly every day (in cycle mode). But I never saw any crash in the near of a roundabout on my GPSMap 62 with my own maps. I think I had this year only one crash of my 62, and here I'm not sure if the fault was not a broken battery. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] no cities found on large areas with --x-split-name-index option
On Tue, Jul 05, Ben Konrath wrote: > On Tue, Jul 5, 2016 at 3:24 PM, Thorsten Kukuk <ku...@suse.de> wrote: > > > > > I guess if you search for cities in the near, they are still shown? > > > > Yeah, I can see the cities but I can't search for them by name. > > It might be a good idea for mkgmap to print a warning or fail when the > index gets too big. But as you said, this might be device specific so it > might not be possible to know exactly where the limit is. This is device specific and it looks like from quite some other factors, too. At least I didn't found anything reliable. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] no cities found on large areas with --x-split-name-index option
On Tue, Jul 05, Ben Konrath wrote: > For the map of Canada, the cities still show up in the list but they aren't > found if you search for them. Removing --x-split-name-index fixes the > problem. It's not a huge issue because I can just remove this option but I > did want to report the problem to you. I saw this already for cities, too. Looks like to me, af if the index get's too big, some devices will not use it anymore. I guess if you search for cities in the near, they are still shown? I have the same problem if my maps have too many POI: in that case, suddenly some POIs will not be found anymore via the normal search. But searching for POIs in the near will display them. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Land flooded
On Wed, May 11, Gary Bamford wrote: > HI, That is what I have done, I produced a gmapsupp.img file using a .txt > file ( the typ info ) and it produces a different map than the same command > but using the same style info but specified as a .typ file. Most likely: your *.txt file is not in sync with your *typ file or contains errors. After creating the *.txt file from my *.typ file, I had to fix a lot of mistakes in it. Thorsten > > > From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf of > Thorsten Kukuk <ku...@suse.de> > Sent: 11 May 2016 08:54 > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Land flooded > > On Wed, May 11, Gary Bamford wrote: > > > HI Gerd. > > > > > > Okay, that leaves just one question, does the conversion from the txt file > > to the typ file have to happen as a separate command, or can i specify the > > txt file as part of a command to make the gmapsupp.img file. > > Instead of specifying the TYP file (file.TYP) you specify the txt > file on the commandline (file.TXT). > > Thorsten > > > > > > > Gary > > > > > > > > From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf of Gerd > > Petermann <gpetermann_muenc...@hotmail.com> > > Sent: 11 May 2016 08:49 > > To: Development list for mkgmap > > Subject: Re: [mkgmap-dev] Land flooded > > > > > > Hi Gary, > > > > > > just to make sure: > > > > mkgmap can compile a gmapsupp with both formats, when you use the *.typ > > file as input it will copy it into to gmapsupp.img, > > > > maybe after adjusting values like product id, I am not sure about that. > > > > When you specify the text file format it will use its typ file compiler to > > create the *.typ file and use that for the gmapsupp.img. > > > > So, when you see differences using these two different ways you may have > > found a problem in the mkgmap typ file compiler. > > > > > > @Steve: I hope that I got this right? > > > > > > Gerd > > > > > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > > Gary Bamford <garybamf...@hotmail.com> > > Gesendet: Mittwoch, 11. Mai 2016 10:05 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Land flooded > > > > > > Hi Gerd > > > > That's where I was going wrong then, I was speciying the typefile as a txt > > file, and not a typ file. > > > > > > http://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler > > > > > > > > I assumed that also meant that the map complier would also allow for a txt > > file input of styles > > > > [http://www.mkgmap.org.uk/static/img/logo.png]<http://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler> > > > > TYP file compiler - > > mkgmap<http://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler> > > www.mkgmap.org.uk > > Another recent feature added is the ability to compile TYP file from the > > .txt format. There is no special option needed, just place the .txt file on > > the command line ... > > > > > > > > > > > > From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf of Gerd > > Petermann <gpetermann_muenc...@hotmail.com> > > Sent: 11 May 2016 07:58 > > To: Development list for mkgmap > > Subject: Re: [mkgmap-dev] Land flooded > > > > > > Hi Gary, > > > > > > not sure what you mean with "when I use the text file output" here. The > > device needs the *.typ format, it > > > > doesn't understand the text file format. Or do you mean that you feed > > mkgmap with the text file format > > > > and the resulting *.typ file doesn't work ? > > > > > > Gerd > > > > > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > > Gary Bamford <garybamf...@hotmail.com> > > Gesendet: Mittwoch, 11. Mai 2016 09:51 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Land flooded > > > > > > Hi Gerd. > > > > > > Thanks for the information. The problem gets a little stranger, I use a > > software package called TYPViewer ( v4.5.35 ) to edit the type files, it > &g
Re: [mkgmap-dev] Land flooded
On Wed, May 11, Gary Bamford wrote: > HI Gerd. > > > Okay, that leaves just one question, does the conversion from the txt file to > the typ file have to happen as a separate command, or can i specify the txt > file as part of a command to make the gmapsupp.img file. Instead of specifying the TYP file (file.TYP) you specify the txt file on the commandline (file.TXT). Thorsten > > > Gary > > > > From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf of Gerd > Petermann <gpetermann_muenc...@hotmail.com> > Sent: 11 May 2016 08:49 > To: Development list for mkgmap > Subject: Re: [mkgmap-dev] Land flooded > > > Hi Gary, > > > just to make sure: > > mkgmap can compile a gmapsupp with both formats, when you use the *.typ file > as input it will copy it into to gmapsupp.img, > > maybe after adjusting values like product id, I am not sure about that. > > When you specify the text file format it will use its typ file compiler to > create the *.typ file and use that for the gmapsupp.img. > > So, when you see differences using these two different ways you may have > found a problem in the mkgmap typ file compiler. > > > @Steve: I hope that I got this right? > > > Gerd > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gary > Bamford <garybamf...@hotmail.com> > Gesendet: Mittwoch, 11. Mai 2016 10:05 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Land flooded > > > Hi Gerd > > That's where I was going wrong then, I was speciying the typefile as a txt > file, and not a typ file. > > > http://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler > > > > I assumed that also meant that the map complier would also allow for a txt > file input of styles > > [http://www.mkgmap.org.uk/static/img/logo.png]<http://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler> > > TYP file compiler - > mkgmap<http://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler> > www.mkgmap.org.uk > Another recent feature added is the ability to compile TYP file from the .txt > format. There is no special option needed, just place the .txt file on the > command line ... > > > > > > From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf of Gerd > Petermann <gpetermann_muenc...@hotmail.com> > Sent: 11 May 2016 07:58 > To: Development list for mkgmap > Subject: Re: [mkgmap-dev] Land flooded > > > Hi Gary, > > > not sure what you mean with "when I use the text file output" here. The > device needs the *.typ format, it > > doesn't understand the text file format. Or do you mean that you feed mkgmap > with the text file format > > and the resulting *.typ file doesn't work ? > > > Gerd > > > > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gary > Bamford <garybamf...@hotmail.com> > Gesendet: Mittwoch, 11. Mai 2016 09:51 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Land flooded > > > Hi Gerd. > > > Thanks for the information. The problem gets a little stranger, I use a > software package called TYPViewer ( v4.5.35 ) to edit the type files, it has > two outputs, one produces a typ file the other produces a txt file. If I use > the typ file output I get the map I expect ( without having to specify > --transparent or --generate-sea=land-tag=natural=background ) the sea is > where it should be, if I use the text file output from TYPViewer then I have > problems. > > > Lessen to learn, use the typ file output. > > > Regards > > > Gary > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question about the overview map
On Mon, Apr 18, franco_bez wrote: > Is it true that the overview map is only used by Mapsource and Bascamp on the > PC, but does not work on the mobile devices themselves ? Yes. > Is there any way to get an overview map working on the mobile device, or do > we have to avoid zooming out too far? For this, there are the resolutions/levels. With every level, I display less informations, and with the highest level/lowest resolution, I only display the same few informations as with the overview map, means mostly highways and the POI of some very big cities. This works pretty well on my 62s. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] House number search - inaccuracy in city assignment
On Sun, Feb 07, Steffen Neumann wrote: > Morning everybody, > > playing around with my Garmin Nuvi I came across a problem with the > house number search. > > The location is: > Germany, Ottobrunn, Ottostrasse 132 > +48.064630, +11.689558 > > The Nuvi shows the address as: > Ottostrasse 132, Hohenbrunn (so the city is Hohenbrunn here) > > But in OSM the house is tagged as: > Ottostrasse 132, Ottobrunn (different city compared to Nuvi) > > So either the Garmin pulled the wrong city out of the house number > information or mkgmap put the wrong info in. Not sure if there is a bug in mkgmap or not, but the data in OSM is clearly not Ok. The address exits twice at the same place: once with addr:city=Ottobrunn, once with addr:city=Hohenbrunn. So maybe mkgmap creates both address records and you only looked at the wrong one? Since everything except this single address is tagged with addr:city=Hohenbrunn and the house is inside of the address boundary of Hohenbrunn, so the addr:city=Ottobrunn looks wrong to me. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search
On Fri, Jan 29, demon.box wrote: > ok thank, I try to use the default-style address section but the result it's > like that: > > <http://gis.19327.n5.nabble.com/file/n5866225/mio2.jpg> > > why I have this? > > Via Luigi Gadola, Osm, ABC > > why , Osm, ABC ?? Looks like you are not using the bounds data and your country options or not correct, too. It would help a lot of you would write, how you generate your maps. Thorsten > thanks > > --enrico > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/address-search-tp5866219p5866225.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
On Sat, Dec 12, Ben Konrath wrote: > On Thu, Nov 12, 2015 at 9:25 PM, Thorsten Kukuk <ku...@suse.de> wrote: > > It's updated every week, if it passes the sanity checks. > > So if too many boundaries are broken, it's not updated. > > I'm curious to know what sanity checks you do? Would it be possible to add > these checks to mkgmap somehow so that a waning message is printed when > there are problems with the bounds? Nothing you could add to mkgmap, it's mostly doing some comparisations of size and number of mkgmap errors/warnings with the previous build. So if something bigger got broken compared to the old version, the boundaries are not updated. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
On Thu, Nov 19, Thomas Morgenstern wrote: > Hi Gerd, congratulation ! i have today new compiled my map again. > The patch works . No idea, why it yesterday did not work. A litle > 'Schönheitsfehler' ( eng. beauty error ???) is : By searching in > Mapssource, each country in the textbox 'Land' is double listed. For > example : 1. as /Dänemark(DNK)/ and 2. as /DNK(Dänemark)/ . Maybee > you can fix this ? Thanks for your work. This behavior depends on your Software and/or Device and not on the map. So nothing you can change with mkgmap. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
On Wed, Nov 18, Thomas Morgenstern wrote:
> Hi,
> sorry , the pach do not work. After using the pach, the situation is
> like befor: 'Wien' as city give me no results->error : 'Die
> ausgewählte Strasse ist in diesem Kartenproduct nicht zulässig'.
> String 'Wien' as region is successfull. But in my opinion Wien is a
> at first a city und second a region. My test-exampel : searching
> for : Praterstrasse 44, Wien.
Works fine for me with this patch.
For me it sounds like you are not using MapSource correct.
I bet you are in the tab "Adresse", not "Stadt", and you did
only enter Wien, no street name. In this case you will get
this error message.
So a user error, not a mkgmap problem.
Thorsten
> regards thomas
> Am 17.11.2015 um 10:43 schrieb Gerd Petermann:
> >
> >Hi Thomas,
> >
> >
> >yes, Wien has admin_level=4. I think it should be treated the same
> >way like Hamburg in Germany:
> >
> >mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level4=Wien
> >{set mkgmap:city='${mkgmap:admin_level4}' }
> >
> >
> >If I hear no complains I'll commit the attached patch on thursday.
> >
> >
> >Gerd
> >
> >
> >
> >
> >*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk
> ><mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas
> >Morgenstern <webmas...@img2ms.de>
> >*Gesendet:* Montag, 16. November 2015 07:51
> >*An:* Development list for mkgmap
> >*Betreff:* Re: [mkgmap-dev] Country unification in address search
> >Hi at all,
> > i found a problem in the city 'Wien' : if i search in Mapsource
> >any address in the city 'Wien', so i type in the textbox 'Stadt'
> >the string 'Wien', textbox 'Bundesland/Provinz' is empty,
> >Mapsource tell me : 'Die ausgewählte Strasse ist in diesem
> >Kartenprodukt nicht zulässig...' . But if i use textbox
> >'Bundesland/Provinz = Wien' and textbox 'Stadt' is empty,
> >Mapsource find it successfull.
> >Maybee must in stylefile-->adress--> Austria a speciall line
> >added, so that 'Wien' is not only a region, but also a city ?
> >
> >Thomas
> >
> >Am 15.11.2015 um 17:38 schrieb Gerd Petermann:
> >>
> >>Hi Felix,
> >>
> >>
> >>my understanding is that both variants find the same addresses
> >>
> >>and that mkgmap stores only one, so the other is produced by
> >>
> >>the Garmin software.
> >>
> >>
> >>Gerd
> >>
> >>
> >>
> >>
> >>*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk
> >><mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix
> >>Hartmann <extremecar...@gmail.com>
> >>*Gesendet:* Sonntag, 15. November 2015 16:07
> >>*An:* Development list for mkgmap
> >>*Betreff:* Re: [mkgmap-dev] Country unification in address search
> >>Thanks for the first patch. In Mapsource "Aut" entry has
> >>disappeared now for me. However I can still select Austria (AT)
> >>respectively AT (Austria). Besides that I see no errors. I mean
> >>there must exist an address with AT in the map - else I could
> >>not select it.
> >>
> >>How can I find such addresses?
> >>
> >>
> >>On 13 November 2015 at 14:45, Gerd Petermann
> >><gpetermann_muenc...@hotmail.com
> >><mailto:gpetermann_muenc...@hotmail.com>> wrote:
> >>
> >>great :-)
> >>Please post any new findings, I am sure the address
> >>rules are not yet complete.
> >>
> >>Gerd
> >>
> >>Von: mkgmap-dev-boun...@lists.mkgmap.org.uk
> >><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
> >><mkgmap-dev-boun...@lists.mkgmap.org.uk
> >><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von
> >>Thorsten Kukuk <ku...@suse.de <mailto:ku...@suse.de>>
> >>Gesendet: Freitag, 13. November 2015 14:23
> >>An: Development list for mkgmap
> >>Betreff: Re: [mkgmap-dev] Country unification in address search
> >>
> >>Hi Gerd,
> >>
> >>On Fri, Nov 13, Gerd Petermann wrote:
> >>
> >>> Hi Thorsten,
> >>>
> >>> I think I found an error in the code, sometimes country
> >>> information is normalized, sometimes no
Re: [mkgmap-dev] Country unification in address search
Hi, after quite some testing, I think we see a problem of a corrupted or wrong index. All tests are done with my GPSMap 62s. On Thu, Nov 12, Thorsten Kukuk wrote: > On my device I have the choice between "Oesterreich" and "AUT". > Below "AUT" I can only find very few streets. I haven't found > out yet why this is the case, the data looks ok. > > There is one example, look at the OSM data for > Schlosscafe, Glorietteallee 1, Eisenstadt. After looking at the OSM data: - All addresses found below "AUT" are tagged in OSM with country=AT This at least tells me, that the mapping AT => AUT is working - The addresses found below "AUT" looks the same way as the ones below "Oesterreich", and according too google and OSM data, the addresses are correct (as used in Austria) and fits with the OSM data. - For many of the addresses found only below "AUT": If I select one, one of the two things will happen: 1. the device crashes 2. I get a list of street names/house numbers/cities I have to choose from, which have nothing to do with the address I searched for. This all let me think that at least my GARMIN device is intrepreting the address index a little bit different or there is a broken pointer somewhere in it. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] postcodes
Hi, On Sat, Nov 14, Gerd Petermann wrote: > Hi Mike, > > I fear I don't yet understand the problem. > You have a road without a housenumber element > next to it and you want to find it with the address search > using the zip code ? I understand him that he has a city name and street name, but no house numbers. So he wants to create the map in a way, that you don't need to enter a house number for address search. Mike, as far as I know that's not possible, but you can enter a random house number in this case. Thorsten > > Gerd > > > Von: mkgmap-dev-boun...@lists.mkgmap.org.uk > <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley > <m...@tvage.co.uk> > Gesendet: Freitag, 13. November 2015 21:37 > An: 'Development list for mkgmap' > Betreff: Re: [mkgmap-dev] postcodes > > Hi Gerd, thanks for the reply. I have tried with the default style and it > does work, but as far as I can see, only for buildings with house numbers. > The buildings and places I am trying to find have names but not numbers. Is > there a way to get it to work without needing house numbers, which are > rarely present in OSM? I'm happy to just locate the street without a > specific building if I have a node with addr:street and addr:postcode. > > Cheers, > Mike > > -Original Message- > From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] > Sent: 09 November 2015 21:17 > To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] postcodes > > Hi Mike, > > AFAIR the search for zip codes in Basecamp should work . > if you use your own style I'd suggest to try the default style. > If that doesn't work as well, and you think that the OSM is correct, please > post a link to your input file and I'll try to reproduce the problem. > If the problem is in your style, follow the hints at the bottom of this > link: > http://www.mkgmap.org.uk/news/2015/06/08/house-number-improvements > > Gerd > > Von: mkgmap-dev-boun...@lists.mkgmap.org.uk > <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley > <m...@tvage.co.uk> > Gesendet: Montag, 9. November 2015 22:01 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] postcodes > > Hi all, I currently have a list of postcodes added to my map, and can see > them in the Postal Code field of the Find Addresses option in basecamp, but > they are not linked to any roads/houses, so any address searches with > postcodes do not find anything. Can anyone please explain what I need to do > to get postcodes working properly? There is a brief mention of > mkgmap:postcode in the help, but it doesn't explain how to use it, and > anyway, I only have the centre points of the postcodes rather than their > enclosing areas. > > Thanks, > Mike > > ___ > 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 mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
Hi Gerd, On Fri, Nov 13, Gerd Petermann wrote: > Hi Thorsten, > > I think I found an error in the code, sometimes country > information is normalized, sometimes not. I am just testing the patch... For Austria it is now working fine for me. I see still some problems in Belgium, but I'm sure that's because our address rules for that country don't fit together with the OSM data. Need to look deeper what is correct. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
Hi, On Thu, Nov 12, Felix Hartmann wrote: > Well I use the bounds file - updated every month or so from here: > http://osm.thkukuk.de/data/bounds-latest.zip It's updated every week, if it passes the sanity checks. So if too many boundaries are broken, it's not updated. On my device I have the choice between "Oesterreich" and "AUT". Below "AUT" I can only find very few streets. I haven't found out yet why this is the case, the data looks ok. There is one example, look at the OSM data for Schlosscafe, Glorietteallee 1, Eisenstadt. It's using "AT" as country, but can be found below AUT, so this mapping works. But "Eisenstadt" cannot be found below "Oesterreich". Interesting is, that "Eisenstadt" is adminlevel 6, not the expected 8. Either the mapping of the admin level is wrong or some boundaries are missing, but in any cases, the fallback in inc/address should match? Maybe this example helps some people here to find out what's going wrong. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Country unification in address search
On Thu, Nov 12, Felix Hartmann wrote: > I will try to find some more myself. But for my understanding such > countries should not even be selectable. The fact that such bogus countries > are selectable - must mean that some objects are found for them - doesn't > it? > I will check up for Canada - as that's where I got twice an error report by > a user. > > > At least for single country maps - maybe there could be an option to > hardcode the country via command line options? As I wrote: the mapping from AT to AUT as country is working, at least in my example. But then something goes wrong. Because AUT should map to Oesterreich according to the LocatorConfig.xml file. Thorsten > On 12 November 2015 at 21:25, Thorsten Kukuk <ku...@suse.de> wrote: > > > > > Hi, > > > > On Thu, Nov 12, Felix Hartmann wrote: > > > > > Well I use the bounds file - updated every month or so from here: > > > http://osm.thkukuk.de/data/bounds-latest.zip > > > > It's updated every week, if it passes the sanity checks. > > So if too many boundaries are broken, it's not updated. > > > > On my device I have the choice between "Oesterreich" and "AUT". > > Below "AUT" I can only find very few streets. I haven't found > > out yet why this is the case, the data looks ok. > > > > There is one example, look at the OSM data for > > Schlosscafe, Glorietteallee 1, Eisenstadt. > > > > It's using "AT" as country, but can be found below AUT, so > > this mapping works. But "Eisenstadt" cannot be found below > > "Oesterreich". > > > > Interesting is, that "Eisenstadt" is adminlevel 6, not the > > expected 8. Either the mapping of the admin level is wrong > > or some boundaries are missing, but in any cases, the fallback > > in inc/address should match? > > > > Maybe this example helps some people here to find out what's going > > wrong. > > > > Thorsten > > > > -- > > Thorsten Kukuk, Senior Architect SLES & Common Code Base > > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > > GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG > > Nürnberg) > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > Floragasse 9/11 > 1040 Wien > Austria - Österreich > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with aeroway=aerodrome as a relation
On Thu, Sep 24, Gerd Petermann wrote: > Hi Nelson, > > there is no special java code in mkgmap to treat aeroways. > I guess you don't use the default style, so I can't say what goes wrong. I would expect this is the drawing priority of objects as defined in the TYP file. My guess is, they are identical, and the device renders them in random order. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with aeroway=aerodrome as a relation
On Thu, Sep 24, Gerd Petermann wrote: > The Garmin devices contain something like a default > typ file, which is used for a map without a typ file. > My understanding is that the defaults are different for > different devices, at least reg. POI. Correct. And this also means, that you cannot create a default style without typ file, which looks identical in all cases on all devices. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Exclude POIs from index
Hi, On Tue, Aug 25, Dave Swarthout wrote: Yes, I already knew that, but thanks. I thought there might be a way to be more restrictive but I now think it's just that the All POIs search is just what it says it is: it displays *ALL* POIs. It's doing exactly what I told it to do. It is not, or more precise: it depends on your firmware. I have one device, which is only showing POIs which are part of the index. So here you can suppress POIs, if you don't put them in the index. But I have also two newer devices, which seem to ignore the index completly and always search for POIs in the image. Here you cannot suppress any POIs. And even worse, this is of course much slower :( Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] What's the meaning of the 'has no region' warnings?
Hi, On Wed, Aug 19, Gerd Petermann wrote: I still have no idea where the data is used. Maybe the device shows some additional info when you drive on a motorway. When Mark Burton committed the code with r984 he did not describe the wanted effect, but he also seemed to be unsure about its positive effects, see here: http://www.mkgmap.org.uk/websvn/listing.php?repname=mkgmaprev=984 and here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001293.html It looks like this is the code responsible for exit:to and similar variables. I played with this some time ago and the informations are shown in mapsource, don't remember anymore about my GPS device. The problem is, with the current way how things are mapped in OSM, it is nearly impossible to fill out this fields correct only with a style file. This would need help of mkgmap itself. That's why I stopped looking at it. But I haven't found a way to search for them, too. In the end, I would let the code stay and not remove it. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Tue, Aug 18, UliBaer wrote: Forgive me, but since routing problems are just discussed here, i also have a problem with bicycle paths: Nearly every time i leave the calculated route for car navigation and the Garmin starts to recalculate the route, it assumes, i'm driving on a bicycle way on the side of the street and it tries to reroute me on the street again at the next crossing. This is strange, since i have set the device for car routing and it tries to reroute on the street again, but nearly every time, if there is a bicycle way, it assumes, i'm on the bicycle way with my car. This does not happen, if there is no bicycle way nearby. I use the style from Ralf Kleineisel and the Garmin device is an etrex Vista HCx. This does not depend on mkgmap version, since it has always done that. Is there a way to avoid this behavior? Did you enable lock on road in your device? The problem sounds like your GPS signal (or the road) is off by some meters. Your Garmin device looks for the nearest way, and it finds the cycleway. So it assumes you are driving on the cycleway. If there is no cycleway, it will use the road, because there is nothing more in the near. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Tue, Aug 18, UliBaer wrote: Hello Thorsten, no, i don't have lock on road enabled. I always thought, this option is only cosmetically changing the position of the marker onto the nearest road. No, it is not cosmetically, if you are on one road, it prevents the device from jumping to another road, at least as long as the difference isn't too big. So in your case, if the device have you on the road, it shouldn't jump anymore to the cycleway. Does this change the way the unit routes? Even if so and the position is nearer to the bicycle way than to the street, wouldn't it also choose the bicycle way in that case or always the road? lock on road follows the road. So, initially, you could be wrong. But at the moment, where you are on the correct road, and you follow the route, you will stay on the right way. I often use the unit for Geocaching and having this feature on is at least counter productive for that activity, so i keep this off. I know that problem very well ;) Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Mon, Aug 17, Marko Mäkelä wrote: It might not even matter if the sidepaths have been entered and connected. For long-distance routing, I believe that the Garmin Edge 705 completely ignores cycleways for the middle section of the route. Cycleways would only be considered for the first and last 5 kilometers or so. Since the roads in Iceland are strange, I debugged some routing errors, where I should go a way 1000km longer then the normal way. The problem is road_class. It looks like, that at least the Garmin GPS 62s, at the beginning prefers increasing road_classes, and later decreasing ones. But in the middle, it is avoiding going up and down. So if you reach road_class=2, and there is a short cycleway with road_class=1, and a very long primary road with road_class=3, Garmin will use the very long primary road. Even if you route for shortest distance. I workarounded this by increasing the road_class of cycleways for my style. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Display of Labels on Maps
On Tue, Aug 11, Bill Lancashire wrote: I have been trying to understand how the display of names and labels on map pages is controlled. I am talking about the following two cases: a) Labels that appear on the map itself which for the purposes here I will call 'Map Labels'. b) Names which appear in a box at the top of the GPS screen when the cursor is placed over an item on the map page which I will refer to as 'Cursor-Over' names. I appreciate the 'Map Label' display is partly controlled by the choice of type code for the polygon, line or point, but can this feature in any way be controlled by either the style configuration or the TYP file when a 'custom' extended code is used?. You should be able to control the size of the font and if it is displayed or not with the TYP file. I think this are the keywords: ExtendedLabels=Y FontStyle=NoLabel (invisible) But depending on your GPS device, this will be overwritten by the firmware or the options the user did choose. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question about ignored no_u_turn restriction
On Sun, Jul 05, Ben Konrath wrote: Does anybody know why this particular restriction is being ignored? Beside that this particular type of restrictions doesn't make any sense to me, I would guess the GARMIN format does not support it. If the to and from ways are the same, I have never seen a sign forbidding u-turns. Only, if you have two ways, structural seperated. But then I should tag the street that way and the restriction will not be ignored. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question reg. exits
Hi Gerd, On Wed, May 20, Gerd Petermann wrote: How ? What category / sub category is it? Ah, you are looking at the menu only. It seems there is no menu entry for it. Since the menu entries are hardcoded in the GPS devices and MapSource, you cannot change that. I don't think there exists some magic flags in the map which changes the menu. I used search for POI in the near and search for all POI. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question reg. exits
On Wed, May 20, Thorsten Kukuk wrote: Only exit:to (my problem here is, if you look how motorway_junction is tagged, that I don't know how to get access to the exit_to/destination tags in the style file. More concret with an example: https://www.openstreetmap.org/node/268575608 This node does not have any information about the destination. So we would need the corresponding tags from the way: https://www.openstreetmap.org/way/24710254 This tags could be: destination/exit_to (both are equal, exit_to is used in the US) destination:ref destination:lanes Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question reg. exits
Hi, On Tue, May 19, Gerd Petermann wrote: Hi all, I just noticed that mkgmap treats POI with 0x2000 = type 0x2800 special. It looks for the tags exit:to=* and exit:facility=* to add extra information to the POI. This info is shown when you click on an exit in Basecamp, it shows the fields Name, Description, and Overnight Parking. The source was added with r984 in 2009 and it seems nobody noticed that these tags don't exist in OSM anymore (or maybe they were typos)? Or maybe that were meant to be set in the style? http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001287.html exit:facility needs to be set by the style, exit:to looks like a proposed OSM tag never introduced. But I admit that I don't really understand the examples in that mail... Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] License and copyright text defects
On Fri, May 15, Paco Tyson wrote: This is the license and copyright text : Your format is wrong. A newline defines a new license, not a new line. GARMIN Software and devices will sort the different licenses and remove duplicates before displaying them. Independently of the exposed results above, I have a few questions and remarks : - Despite providing a lower case copyright text, the result text is in upper case. Is it done by mkgmap ? Is it a Garmin format limitation ? It's done by the Software/Device displaying this. - In the default license/copyright text, one can read Program released under the GPL and PROGRAM LICENCED UNDER GPL V2. I assume it's the mkgmap license, instead I'd expect here the license of the produced Garmin map. The default license cannot show the license of your map, the mkgmap devlopers don't know them. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] EU map too big?
Hi, On Wed, May 13, Minko wrote: I fear that the Europe map became too big for mkgmap to put it into one mapset. I have now 2293 img tiles that I wanted to combine with mkgmap-r3590 The java memory is set to -Xmx8000m, the error message is as follows: Maybe you should write more in detail what exaclty you try to do? For one gmapsupp, whole europe is of course far too big. And with 2293 img tiles you have too much, too. The number of img tiles is limited to 2000 for older devices. Don't know where the limit is for newer devices, I think 5000 tiles. I have no problems creating the data for whole europe with about 1300 img tiles. But I use --tdbfile and not --gmapsupp. Afterwards I can select the img tiles I need and write them with MapSource to a GPS device. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] housenumber2 branch
Hi, On Tue, May 12, Gerd Petermann wrote: Hi all, did anybody test the branch during the last days? I'm using it, but I didn't test it systematically. Until know I'm happy with the results. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fw: Help
On Mon, May 04, Gerd Petermann wrote: Hi Thorsten, thanks for the feedback. What do you think about my proposed solution? I like the idea. But I'm currently still thinking, if this really works. For something like place=city, the place tag and the name are the most important thing mostly used. But what about population? What to do if only one of the two POI has full informations? Even more complicated would be something like amenity=restaurant, if somebody adds a POI and adds all tags to the building, too (I think this is bad tagging and the POI should be removed from the OSM data, but that's another problem. When are this two POIs really the same? And what if the tags sligthly differ? Thorsten Gerd Date: Mon, 4 May 2015 07:48:21 +0200 From: ku...@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Fw: Help Hi, On Mon, May 04, Gerd Petermann wrote: I am not sure if the OSM data is okay, but I think we probably have more sure cases. Did anybody try to solve that already? Do you see a general rule which might be implemented as filter before or after style processing? The OSM data is okay, it is defined this way in the wiki. I have no solution for the city part, but I use for example: place=country mkgmap:area2poi!=true [0x1500 level 5-7] But I only do that for POIs, where I know that you will have duplicates or where I don't care if one is missing. But for cities, this is not the case, since some have only a place key, otheres none (only boundary), and others both. But I don't want missing cities in the index, so I accept sometimes two. Thorsten My 1st approach would be this: After style processing, keep a map that relates the Garmin POI with the original node, one map for each type. If two or more POI have the same type and label(s), remove those where the OSM element has the mkgmap:area2poi=true tag (maybe also the ones with mkgmap:line2poi=true. Gerd From: thunder...@gpsinfo.com.br To: mkgmap-dev@lists.mkgmap.org.uk Date: Sun, 3 May 2015 17:10:57 -0300 Subject: Re: [mkgmap-dev] Fw: Help Hi Gerd. thanks for your quick response and congratulations to the whole team for the excellent work developed. Yes, it's POI generated by the add-as-to-area option and only when the boundary relationship. For the other areas we are not having problem. It is a filter we need and we do not know how to do and where to apply. A filter that only remove the label place when inserted into the boundary relationship. The filter would not need to collect all the POI. Would collect only those generated by the boundary area due to add-to-area option. We have a rule for admin_centre and these were included in the relationship, but unfortunately many admin_centre were excluded relationships. Could you help us? [] s Marcio -Mensagem Original- From: GerdP Hi Marcio, okay, so this is about the POI generated by the add-pois-to-area option and other OSM nodes with similar tags and the problem is that you cannot know if both exist or only one? Well, I think there is no trick to solve that problem, but it should be easy to implement a filter. Something like this: Collect all POI with the same type, and when two have the same label(s), select the one that has a special tag, or just use the first. I assume we have to limit this filter to special POI types. Does that sound like a solution? Gerd ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http
[mkgmap-dev] Request for feature: show wrong roundabouts
Hi, from time to time I see this in the log files: Attention: Tile contains both drive-on-left (1) and drive-on-right roads (15389) The one drive-on-left road is clearly a bug in the OSM data. But finding that is pretty hard (I found one once by accident ...). I wanted to try to implement this myself, but I currently don't see that I have the time to dig into the code myself, that's why I write here my idea: Could we add an option (--x-report-wrong-direction or something similar), and if drive-on=left or drive-on=right is set, write the roads with the wrong direction into the log file? If drive-on= isn't set at all or to detect, nothing should be written. So, additonal to increasing the counter, write the ID at that time to the log, too. Thanks, Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Request for feature: show wrong roundabouts
Hi Gerd, On Mon, May 04, Gerd Petermann wrote: The check works like this: For each road, the LocationHook sets the values like mkgmap:admin_level2 .. mkgmap:admin_level10 These are used in inc/address to set the mkgmap:country which in turn is used to get the drive_on rule from resources\LocatorConfig.xml When this returns a wrong result, I guess that either the LocationHook sets a wrong mkgmap:admin_level2 or the country is missing in LocatorConfig.xml. Ok, I had in mind that we count the roundabouts. But if this is not the case ... For example on the channel islands, there are a log of wrong mapped roundabouts (according to the OSM wiki), and I hoped to find them easier. But getting a warning that a country is missing in LocatorConfig.xml or that mkgmap:admin_level2 could be wrong would help already a lot. Else this SEVERE log is pretty useless. Thanks, Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Request for feature: show wrong roundabouts
Hi Gerd, On Mon, May 04, Gerd Petermann wrote: attached is a first patch for StyledConverter. I can imagine that the problem is caused by ferry connecting a drive-on-left and a drive-on-right country, so I decided to remove them from the counting. Thanks, works. For my now tested cases it really seems to be caused by ferry connections, I don't get a SEVERE message anymore. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fw: Help
Hi, On Mon, May 04, Gerd Petermann wrote: I am not sure if the OSM data is okay, but I think we probably have more sure cases. Did anybody try to solve that already? Do you see a general rule which might be implemented as filter before or after style processing? The OSM data is okay, it is defined this way in the wiki. I have no solution for the city part, but I use for example: place=country mkgmap:area2poi!=true [0x1500 level 5-7] But I only do that for POIs, where I know that you will have duplicates or where I don't care if one is missing. But for cities, this is not the case, since some have only a place key, otheres none (only boundary), and others both. But I don't want missing cities in the index, so I accept sometimes two. Thorsten My 1st approach would be this: After style processing, keep a map that relates the Garmin POI with the original node, one map for each type. If two or more POI have the same type and label(s), remove those where the OSM element has the mkgmap:area2poi=true tag (maybe also the ones with mkgmap:line2poi=true. Gerd From: thunder...@gpsinfo.com.br To: mkgmap-dev@lists.mkgmap.org.uk Date: Sun, 3 May 2015 17:10:57 -0300 Subject: Re: [mkgmap-dev] Fw: Help Hi Gerd. thanks for your quick response and congratulations to the whole team for the excellent work developed. Yes, it's POI generated by the add-as-to-area option and only when the boundary relationship. For the other areas we are not having problem. It is a filter we need and we do not know how to do and where to apply. A filter that only remove the label place when inserted into the boundary relationship. The filter would not need to collect all the POI. Would collect only those generated by the boundary area due to add-to-area option. We have a rule for admin_centre and these were included in the relationship, but unfortunately many admin_centre were excluded relationships. Could you help us? [] s Marcio -Mensagem Original- From: GerdP Hi Marcio, okay, so this is about the POI generated by the add-pois-to-area option and other OSM nodes with similar tags and the problem is that you cannot know if both exist or only one? Well, I think there is no trick to solve that problem, but it should be easy to implement a filter. Something like this: Collect all POI with the same type, and when two have the same label(s), select the one that has a special tag, or just use the first. I assume we have to limit this filter to special POI types. Does that sound like a solution? Gerd ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RFC: naming unnamed roads
Hi, On Thu, Apr 30, Gerd Petermann wrote: This happens when 1) an unnamed service road or footway is connecting the house with a road named xyz 2) unnamed cylceways / footways are between the house and the named road 3) typos in the addr:street tag or the mkgmap:street tag prevent a clear match, e.g. the road is named Alte Chausseestraße and the houses have (probably wrong) Alte Chaussestraße (single e), or the addr:street tag is completely wrong, means, no street with a name like that is close. 4) a named road is close to one side of the house but an unnamed track/footway is closer on an other side. [...] Any ideas ? I would do the following: 1) is clear, use the service road or footway. 2) if they are not 1), ignore them and put the address on the named road. Because, most of the time in reality, there are connections between the named road and the footway, but the mapper didn't add them. Since the footway is somehow connected with the named road, you can end up with a 4.5km detour. I had that on Sunday, when I used a POI as destination for routing ... If the ways are not connected somewhere, you have routing islands and you will get a routing error, which is as worse. 3) I would ignore the house and write it as error in the log files, so that somebody can fix the wrong street name. 4) Since you calculates the distance between the house and the roads, you could calculate the distance between the two points of the roads, too. If this is larger as the distances between the house and both roads, use the named road. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Adress in a part of a town
On Sat, Apr 25, Arndt wrote: Thanks for the Info. I tried to find Kölner Straße in a Garmin Map (City Navigator) Both values are possible, Remscheid or Lennep. The result searching for Lennep is: Kölner Straße, Lennep (Remscheid), DEU The result for Remscheid is Kölner Straße, Remscheid, Remscheid, DEU Perhaps the same is possible with mkgmap? It maybe possible to add additional citys to the index with mkgmap, I don't know, but in this case the OSM data misses already the necessary informations (admin_level boundary). So the prerequisite is that at first somebody enters this data to OSM. Thorsten Best regards Arndt Thorsten Kukuk ku...@suse.de hat am 24. April 2015 um 23:48 geschrieben: Hi, On Fri, Apr 24, arndt wrote: Hi @all, is it possible to find a adress enter a part of a town? For example: i search kölner street in Remscheid Lennep. Lennep is a part of Remscheid. When i enter Lennep in the adress box there is no result. When i enter Remscheid the adress will be found. http://spike-01.osm.ichosted.org.uk/node/58639041 As you can see from the data and wikipedia: the city name is Remscheid and nothing else. Thus every address has Remscheid has city name. In theory you could modify the rules for mkgmap:city in your own style, so that Lennep is used as city and not Remscheid (which means, you could only search for Lennep and will not find it anymore in Remscheid). But in this case it's not possible, since there are no admin boundaries for Lennep (I think in this case it would be admin_level 9-11). Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Adress in a part of a town
Hi, On Fri, Apr 24, arndt wrote: Hi @all, is it possible to find a adress enter a part of a town? For example: i search kölner street in Remscheid Lennep. Lennep is a part of Remscheid. When i enter Lennep in the adress box there is no result. When i enter Remscheid the adress will be found. http://spike-01.osm.ichosted.org.uk/node/58639041 As you can see from the data and wikipedia: the city name is Remscheid and nothing else. Thus every address has Remscheid has city name. In theory you could modify the rules for mkgmap:city in your own style, so that Lennep is used as city and not Remscheid (which means, you could only search for Lennep and will not find it anymore in Remscheid). But in this case it's not possible, since there are no admin boundaries for Lennep (I think in this case it would be admin_level 9-11). Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search and case significance of street name
Hi Andrzej, On Sat, Apr 18, Andrzej Popowski wrote: If any element processed later has a name like ABC street or abc Street which we consider as a street name, we will use Abc Street again. I'm not sure what for are used names from this table. I don't think that case could be important for comparison of street names. But I would prefer to see street name on a map with the original spelling. But what is the original spelling? And more important, what's the right one? name of highway? name of route=street? addr:street? Yes, some people add addr:street to highways ... During the last days I looked at the warnings from mkgmap in regards to mismatch of street names, and I can only say, that typos are everywhere. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change inc/address to be a standalone ?
Hi,
On Thu, Apr 16, Gerd Petermann wrote:
I think we should change that.
My proposal:
Instead of inc/address we have a file address (on the same level
like points, lines, etc)
this file is evaluated before the rules in points/lines/polygons
when it exists. Probably the class RuleFileReader should make sure that
the files points/lines/polygons do not include another
inc/address.
Currently I include inc/address in the middle of a rules file,
so that I can fix highway names and so on.
Like:
name!=* place_name=* { name '${place_name}' }
name!=* loc_name=* { name '${loc_name}' }
or:
tiger:name_base=* tiger:name_type=Rd name!=*
{name '${tiger:name_base} Road'}
If address becomes a standalone file executed before, I have
to put all rules from lines, points and polygons (yes, I use
inc/address in polygons, too, for mkgmap:city and mkgmap:country
specific rules) before inc/address into address. This does not
make it easier to maintain the style.
Thorsten
--
Thorsten Kukuk, Senior Architect SLES Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change inc/address to be a standalone ?
On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
okay, I think I understand now. You don't use
any of the possible tricks in your style, but
you don't want to loose the possibility to do it.
Right?
No, I already use some of the tricks to prevent that
inc/address set mkgmap:street is set wrongly due to bad
tagging.
I can workaround them, but yes, I don't want to loose
the possibility to fix them.
Thorsten
I think that is a good point against my proposal.
Gerd
Date: Thu, 16 Apr 2015 09:08:22 +0200
From: ku...@suse.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
On Thu, Apr 16, Gerd Petermann wrote:
Hi Thorsten,
my thinking was that inc/address does not set any
tags which are not prefixed with mkgmap:
I see that your inc/address is a bit different to that in the default
style,
but the only significant difference that I found is this rule:
mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set
style:lang=german}
So, I see no problem as your inc/address also doesn't set name or
place_name.
What do I miss?
This were only examples, the result is used by me to set mkgmap:street
in some cases to prevent inc/address from setting it (workaround for some
bad tagging, where people add addr:street to a highway, e.g.).
So in this special case I could add:
highway=* name=* addr:street=* {delete addr:street}
to address, but I'm afraid that we loose a lot of flexible to
fix wrong data by rules. And I'm not sure if adding the workarounds
from points/lines/polygons to address is really always a good thing
or can work.
Thorsten
--
Thorsten Kukuk, Senior Architect SLES Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
___
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
--
Thorsten Kukuk, Senior Architect SLES Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] inc/address and --housenumbers
On Tue, Apr 14, GerdP wrote: 2) A road may be the border or very close to the border of a city. Houses on the left side are in city A, houses on the other side are in city B. I think in this case we should add the road twice to the map so that address search works. The problem: With the default style most houses do not have the mkgmap:city tag because no map object is created for them. I think a quick and clear solution would be to add a tag mkgmap:execute_finalize_rules=1 to each element with addr:housenumber to tell mkgmap that even if no map element is created the finalize rules should be executed. My solution for my own style is quite simple here: I include 'inc/address' very early at the beginning of points/lines/polygons style files. Has also the advantage, that mkgmap:street is set to the original street name, before we add suffixes or prefixes like '(B101)' or something similar. And I can use mkgmap:country or something similar in my style files. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Backtrace with housenumber branch
Hi, with the latest releases of the housenumber branch, including r3535, I get the following backtrace when building my bicycle map (the trunk version is fine and works): java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addThroughRoute(RoadNetwork.java:651) at uk.me.parabola.mkgmap.general.MapDetails.addThroughRoute(MapDetails.java:135) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:658) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627) at java.lang.Thread.run(Thread.java:863) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 It's the bicycle style from my web page, and I call mkgmap with: mkgmap --style-file=bicycling --family-name=TK-DACH-Bicycling --country-name=DACH --country-abbr=DACH --area-name=DACH --latin1 --license-file=TK-DACH-Bicycling_license.txt '--copyright-message=OpenStreetMap contributors, ODbL. See: http://www.openstreetmap.org/copyright. TK-DACH-Bicycling based on data from 2015-04-13.' --series-name=TK-DACH-Bicycling --product-version=150414 --add-pois-to-areas '--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance' --reduce-point-density=4 --reduce-point-density-polygon=8 --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 --make-opposite-cycleways --name-tag-list=name,place_name,loc_name --transparent --no-poi-address -c mkgmap.cfg --gmapsupp -c maps.cfg --description=TK-DACH-Bicycling TK_DACH.TYP Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Backtrace with housenumber branch
On Tue, Apr 14, Thorsten Kukuk wrote: Hi, with the latest releases of the housenumber branch, including r3535, I get the following backtrace when building my bicycle map (the trunk version is fine and works): java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addThroughRoute(RoadNetwork.java:651) at uk.me.parabola.mkgmap.general.MapDetails.addThroughRoute(MapDetails.java:135) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:658) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627) at java.lang.Thread.run(Thread.java:863) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 It's the bicycle style from my web page, and I call mkgmap with: mkgmap --style-file=bicycling --family-name=TK-DACH-Bicycling --country-name=DACH --country-abbr=DACH --area-name=DACH --latin1 --license-file=TK-DACH-Bicycling_license.txt '--copyright-message=OpenStreetMap contributors, ODbL. See: http://www.openstreetmap.org/copyright. TK-DACH-Bicycling based on data from 2015-04-13.' --series-name=TK-DACH-Bicycling --product-version=150414 --add-pois-to-areas '--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance' --reduce-point-density=4 --reduce-point-density-polygon=8 --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 --make-opposite-cycleways --name-tag-list=name,place_name,loc_name --transparent --no-poi-address -c mkgmap.cfg --gmapsupp -c maps.cfg --description=TK-DACH-Bicycling TK_DACH.TYP I forgot, the input file: http://osm.thkukuk.de/tmp/71200177.osm.pbf And only the style: http://osm.thkukuk.de/tmp/bicycling.zip Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] SEVERE internal error in restriction relation
Hi, On Wed, Apr 08, Gerd Petermann wrote: Hi Thorsten, with trunk version r3528 I've changed the code to report the restriction relation, but I was not able to reproduce the problem with the input file. Did you use your style files dated 2015-02-19, 10:27 ? Something newer, I have uploaded that now, but the changes there shouldn't have any impact on this. I still see the error: 2015/04/09 11:59:51 SEVERE (RestrictionRelation): 71200051.osm.pbf: Turn restriction (no_right_turn) http://www.openstreetmap.org/relation/4769034 (at http://www.openstreetmap.org/?mlat=53.084337mlon=8.851024zoom=17) internal error: number of via points and via ways no longer fits And yes, this restriction is really strange... Thorsten Gerd Date: Wed, 8 Apr 2015 11:14:15 +0200 From: ku...@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] SEVERE internal error in restriction relation Hi, Today I found in the log files this severe error message: 2015/04/08 03:16:45 SEVERE (RestrictionRelation): 71200051.osm.pbf: internal error: number of via points and via ways no longer fits osm.thkukuk.de/tmp/71200051.osm.pbf is the input file. I don't know, but at least for me it would be helpful to have a reference, at least the coordinates, where this happens, so that I could check if the OSM data is buggy or what else the reason could be. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] addr:place support
On Thu, Apr 09, Andrzej Popowski wrote: Although the wiki says that either addr:place or addr:street should be used I see many nodes with both. IMHO use addr:street and ignore addr:place. Most probably addr:place is incorrectly set instead of addr:city, which you get from other data anyway. I think this is a problem of some editors, which asks for all of this keys, and people think they need to fill out every field. If we have addr:place and addr:street, I would ignore addr:place, too. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] addr:place support
On Tue, Apr 07, Andrzej Popowski wrote: Hi Gerd, I think this is plausible, the routing algo searches for the closest road and tries to build a route to the other house, but that fails because it finds the pseudo roads which are not routable (2 and 3) or not connected to the road network (4). This is not how Mapsource usually behave. I don't know about Mapsource, but this is how the Garmin GPSMap 62s behaves. It is looking for the nearest road, whatever this is, and tries to route from that. If this nearest road is not connected, you will get a routing error. Your example with two points only works, if the closest road is routeable and connected. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: housenumbers2-r3502
On Thu, Mar 26, GerdP wrote: Besides that the problem with Röhnstraße is that it is sometimes written Röhnstraße and sometimes Röhnstrasse (with ss) Maybe we should add some rules in the default style to correct these on the fly. In the past there was a bot fixing this issues in the OSM database. Either the street is near a border, so that the bot is not sure if it is in germany, or it is currently not running anymore. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] addr:interpolation ways not along road
Hi, On Tue, Mar 24, Gerd Petermann wrote: 2) On the other hand, a lot of the addr:interpolation ways in Canada are wrong, e.g. http://www.openstreetmap.org/way/75809612 crosses the road. Yes, North-America is suffering a lot from this automatic imports. They hoped to have quick a base and then that mapper will fix it, but in the end nobody was interested in fixing data, what was there was good enough for them ... If mkgmap only ignores this wrong addr:interpolation way it will still use the obviously wrong odd house number 3367 for the road side that has even numbers. So, mkgmap should also ignore that number. As it is sometimes difficult to decide which of the two numbers is wrong, I decided that it is okay to ignore both. If you find a wrong addr:interpolation, you should ignore not only the way, but all the points, too. If the way is wrong, then the points are most likely wrong, too. Thorsten I guess I have to find more detailed rules :-( Gerd Date: Tue, 24 Mar 2015 08:35:22 +0100 From: ku...@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] addr:interpolation ways not along road Hi, On Mon, Mar 23, GerdP wrote: Hi all, I wonder if mkgmap should treat this a valid addr:interpolation way: http://www.openstreetmap.org/way/32922365 The wiki says: How to interpolate the house numbers belonging to the way along the respective street. but this way connects house numbers which are up to 170 m away from the road named Bergweg, so I think it is not along the respective street. The addr:interpolation way is valid in the regard that it matches reality. If this is good tagging is another question. And if the street really stops that early: I don't know, the pictures of bing and google are not good enough for this. But I know that this will not really help you. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] addr:interpolation ways not along road
Hi, On Mon, Mar 23, GerdP wrote: Hi all, I wonder if mkgmap should treat this a valid addr:interpolation way: http://www.openstreetmap.org/way/32922365 The wiki says: How to interpolate the house numbers belonging to the way along the respective street. but this way connects house numbers which are up to 170 m away from the road named Bergweg, so I think it is not along the respective street. The addr:interpolation way is valid in the regard that it matches reality. If this is good tagging is another question. And if the street really stops that early: I don't know, the pictures of bing and google are not good enough for this. But I know that this will not really help you. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search and mixed index
On Thu, Feb 26, Gerd Petermann wrote: Hi all, maybe you can help me with an open problem. I am not sure sure if this is a case of garbage-in - garbage-out or not. I see a lot of houses with plausible tags addr:housenumber and addr:street which are close to a road that has no name or a different name. A typical example is a village like Stühren: http://www.openstreetmap.org/node/378300184#map=17/52.89235/8.71508 Almost all buildings are all tagged with addr:street=Stühren, but the main road through the village is the L340: http://www.openstreetmap.org/way/26701165 which has no name and many buildings are close to it. I'm pretty sure that this is a bug in the OSM data. According to several source the L340 in Stuehren is called Stuehren, too. I had that already in my old hometown: at some point in the past somebody did remove the street names from all streets, which are B* or L*. I think the postal address for these buildings is really something like Stühren 28, 27211 Bassum,Germany Yes, that's correct. With trunk and r3477 in the housenumber2 branch I see rather bad results for this because the housenumbers are only added to those roads that have the name Stühren. I wonder if the housenumber option should add the name Stühren to (a part of) L340 ? Adding the name to a part of L340 would be the right thing. But this should be done in the OSM data, not by mkgmap. My problem with the automatic mkgmap approach is: there are enough cases, where you cannot reach from such a road the building. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search and mixed index
Hi Gerd, On Thu, Feb 26, Gerd Petermann wrote: Unnamed service roads leading to many houses with addr:street tag. I wonder if mkgmap could give them the name of the road so that address search finds them in the service road while road search would only show the original list. That's why I used mixed index in the subject. I like that part. If there is an unnamed road starting at a named road and ending nowhere, it would be good if mkgmap used that road. That would help a lot for better routing in case of an address search. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] SEVERE log messages from housenumber2 r3471
On Mon, Feb 23, Gerd Petermann wrote: Hi Thorsten, yes, please upload the file. Maybe it is related to tile boundaries. We have no special code in splitter to make sure that house numbers are complete. http://osm.thkukuk.de/tmp/71300045.osm.pbf The options I did use (stripped down): mkgmap --precomp-sea=sea --bounds=bounds --location-autofill=bounds,is_in,nearest --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --reduce-point-density=4 --reduce-point-density-polygon=8 --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 --make-opposite-cycleways --name-tag-list=name,place_name,loc_name --link-pois-to-ways --route --net --index --housenumbers --gmapsupp -c maps.cfg Thorsten Gerd Date: Mon, 23 Feb 2015 08:53:27 +0100 From: ku...@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] SEVERE log messages from housenumber2 r3471 Hi Gerd, On Mon, Feb 23, Gerd Petermann wrote: Hi Thorsten, I was able to reproduce the unexpected result messages, but I found no zero length interval message for Germany, Austria and an older Czech-republic download from end of 2014. Maybe that one depends on the style? I can reproduce it with the default style: 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: detected unplausible co mbination of intervals in Viovka 130..75 and 79..79 houses: right [130(26), 12 7(26), 75(26)] right [79(0)] road id(s):127718589, 25464598 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: duplicating number node in road id=127718589, Viovka (n26),N,0,0,B,130,75 [] [130(26), 127(26), 75(26 )] 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: zero length interval ad ded in street id=127718589, Viovka (n26),N,0,0,B,130,75 == (n26),N,0,0,N,0,0 + (n27),N,0,0,O,127,75 2015/02/23 08:33:12 SEVERE (ExtNumbers): 71300045.osm.pbf: zero length interval has no numbers in road id=127718589, Viovka 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: detected unplausible combination of intervals in Viovka 127..75 and 79..79 houses: right [127(27), 75(27)] right [79(0)] road id(s):127718589, 25464598 I can upload 71300045.osm.pbf later when I'm in the office. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ 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 -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] SEVERE log messages from housenumber2 r3471
Hi Gerd, On Mon, Feb 23, Gerd Petermann wrote: Hi Thorsten, I was able to reproduce the unexpected result messages, but I found no zero length interval message for Germany, Austria and an older Czech-republic download from end of 2014. Maybe that one depends on the style? I can reproduce it with the default style: 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: detected unplausible co mbination of intervals in Viovka 130..75 and 79..79 houses: right [130(26), 12 7(26), 75(26)] right [79(0)] road id(s):127718589, 25464598 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: duplicating number node in road id=127718589, Viovka (n26),N,0,0,B,130,75 [] [130(26), 127(26), 75(26 )] 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: zero length interval ad ded in street id=127718589, Viovka (n26),N,0,0,B,130,75 == (n26),N,0,0,N,0,0 + (n27),N,0,0,O,127,75 2015/02/23 08:33:12 SEVERE (ExtNumbers): 71300045.osm.pbf: zero length interval has no numbers in road id=127718589, Viovka 2015/02/23 08:33:12 INFO (ExtNumbers): 71300045.osm.pbf: detected unplausible combination of intervals in Viovka 127..75 and 79..79 houses: right [127(27), 75(27)] right [79(0)] road id(s):127718589, 25464598 I can upload 71300045.osm.pbf later when I'm in the office. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] SEVERE log messages from housenumber2 r3471
Hi, with the r3471 (housenumber2), I see some SEVERE log messages from mkgmap: build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:42:33 SEVERE (ExtNumbers): 71200082.osm.pbf: zero length interval has no numbers build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:44:44 SEVERE (ExtNumbers): 71200091.osm.pbf: zero length interval has no numbers build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:52:08 SEVERE (HousenumberGenerator): 71200120.osm.pbf: Hlvkova 1336 http://www.openstreetmap.org/way/237856642 unexpected result in plausibility check, counters: 0 0 build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 07:58:30 SEVERE (ExtNumbers): 71700081.osm.pbf: zero length interval has no numbers build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:02:06 SEVERE (HousenumberGenerator): 71700095.osm.pbf: 's-Gravenweg 332 +http://www.openstreetmap.org/node/2793534692 unexpected result in plausibility check, counters: 0 0 build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:03:21 SEVERE (ExtNumbers): 71700100.osm.pbf: zero length interval has no numbers build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:03:35 SEVERE (HousenumberGenerator): 71700101.osm.pbf: Guldenberg 1 +http://www.openstreetmap.org/node/2773681907 unexpected result in plausibility check, counters: 0 0 Same for Czech Republic, too. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] SEVERE log messages from housenumber2 r3471
On Sat, Feb 21, GerdP wrote: Hi Thorsten, I've no time this weekend, will look at it on Monday. Which is absolute no problem, enjoy your weekend! I've committed r3474 which reports the road id in the zero length interval message. Ok, I will update to r3474 and test tomorrow. Thorsten Gerd Thorsten Kukuk wrote Hi, with the r3471 (housenumber2), I see some SEVERE log messages from mkgmap: build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:42:33 SEVERE (ExtNumbers): 71200082.osm.pbf: zero length interval has no numbers build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:44:44 SEVERE (ExtNumbers): 71200091.osm.pbf: zero length interval has no numbers build/DACH/basemap/mkgmap.gmapsupp.log:2015/02/21 04:52:08 SEVERE (HousenumberGenerator): 71200120.osm.pbf: Hlvkova 1336 http://www.openstreetmap.org/way/237856642 unexpected result in plausibility check, counters: 0 0 build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 07:58:30 SEVERE (ExtNumbers): 71700081.osm.pbf: zero length interval has no numbers build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:02:06 SEVERE (HousenumberGenerator): 71700095.osm.pbf: 's-Gravenweg 332 +http://www.openstreetmap.org/node/2793534692 unexpected result in plausibility check, counters: 0 0 build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:03:21 SEVERE (ExtNumbers): 71700100.osm.pbf: zero length interval has no numbers build/benelux/basemap/mkgmap.gmapsupp.log:2015/02/21 08:03:35 SEVERE (HousenumberGenerator): 71700101.osm.pbf: Guldenberg 1 +http://www.openstreetmap.org/node/2773681907 unexpected result in plausibility check, counters: 0 0 Same for Czech Republic, too. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/SEVERE-log-messages-from-housenumber2-r3471-tp5834456p5834469.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] housenumber2 branch
Hi, On Wed, Feb 18, Gerd Petermann wrote: Hi all, I think r3466 is now stable enough for a first public test. It is fully compatible with trunk r3449. For, it looks like it's ending in an endless loop. The input file: http://osm.thkukuk.de/tmp/71200082.osm.pbf The last 2000 lines of the log file: http://osm.thkukuk.de/tmp/mkgmap.log It's my basemap style. But the default style shows the same problem. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Railway tracks drawn around station buildings
On Mon, Feb 09, Gerd Petermann wrote:
Hi Thorsten,
yes, got that in my mind when I proposed my 2nd alternative,
but it should probably be something like
railway=* !(tunnel=yes) (building=no ! building!=*) [0x14 resolution 22]
Or maybe we should add a general rule
building=no {delete building}
somewhere at the start of lines?
Great idea. I will do that now with my style, makes it clearly
better readable and avoids more such pitfalls.
Thorsten
--
Thorsten Kukuk, Senior Architect SLES Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham
Norton, HRB 21284 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POI Index
Hi, On Wed, Feb 04, GerdP wrote: in the subject you mention the index. AFAIK we can easily add a new tag like mkgmap:add-to-index=no which tells mkgmap which map objects are not be placed in the index. I am not so sure about the effect. If I got it right, the device might still show the POIs in the lists, but without index that might be slower. Depends on the device/firmware. My GPSMap 60CSx only shows this POIs, which are part of the index and not in special ranges. Searching for POIs is very fast. My GPSMap 62s shows always all POIs, and searching for POIs is always slow. I need to do a reset after updating the maps to have the search useable. My impression is, it does not use the index at all. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POI Index
Hi, On Wed, Feb 04, Mike Baggaley wrote: Hi, does anyone know whether it is possible to create POIs, but not have them listed in the Find Points of Interest list? I have things like gates and barriers displayed on my map, but if possible want them to not be searchable. Alternatively, is there another way of displaying these on the map? Depends on the GARMIN firmware. With older devices, some POI id ranges do not shown up in the search lists, but with newer devices/firmwares, it seems that all show up. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with subversion?
Hi Steve, On Mon, Dec 08, Steve Ratcliffe wrote: Hi Thorsten What is the URL you are using and the client? The client is subversion 1.8.10 The command is svn co http://svn.parabola.me.uk/mkgmap/branches/mixed-index But Nelson seems to be right, this only happens from our company network, I tried it this morning from home and there it worked. Thorsten Thanks Steve I tried to checkout the mixed-index branch, but after some files I get this error message: Updating '.': svn: E000104: Error retrieving REPORT: Connection reset by peer That's true for everything in subversion, not only the mixed-index branch. Thorsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with subversion?
On Tue, Dec 09, Steve Ratcliffe wrote: Hi Thorsten The client is subversion 1.8.10 The command is svn co http://svn.parabola.me.uk/mkgmap/branches/mixed-index [as an aside, you should use svn.mkgmap.org.uk, as I can't guarantee that svn.parabola.me.uk will always work. I don't believe it will make any actual difference at the moment though.] Ok, I adjusted the wiki: http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Subversion_access But you should fix the mkgmap.org.uk webpages ;) http://www.mkgmap.org.uk/page/main But as you already guessed, this does not solve the problem. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with subversion?
On Tue, Dec 09, Nelson A. de Oliveira wrote: On Tue, Dec 9, 2014 at 1:54 PM, Thorsten Kukuk ku...@suse.de wrote: But as you already guessed, this does not solve the problem. Not really the solution but does git-svn work? git svn clone http://svn.mkgmap.org.uk/mkgmap/trunk No, same error message. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problems with subversion?
Hi Steve, On Tue, Dec 09, Steve Ratcliffe wrote: Hi Thorsten I have enabled some more web logging, if you get a chance to repeat the checkout and let me know the exact time, I may be able to see what is happening.. I have done a svn up at 20:01 CET and a svn co for the mixed-branch at 20:04 CET. But I think this is a bug in subversion 1.8.10. On other machines in the same subnet, it works fine. But this machines have all an older subversion version installed. I will speak with our developers tomorrow, if they know something. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Problems with subversion?
Hi, I tried to checkout the mixed-index branch, but after some files I get this error message: Updating '.': svn: E000104: Error retrieving REPORT: Connection reset by peer That's true for everything in subversion, not only the mixed-index branch. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
