Re: [mkgmap-dev] Request for feature: show wrong roundabouts
Hi Felix, I guess you mean the "Attention: Tile contains both drive-on-left (2917) and drive-on-right roads (3647)" message. it was Steve who suggested to "warn loudly" . http://gis.19327.n5.nabble.com/Manage-drive-on-left-drive-on-right-in-resources-LocatorConfig-xml-tp5825418p5825490.html and at that time we believed that we would change mkgmap to allow non-rectangular tile boundaries to fix the problem soon. I don't mind to change the severity level of the message to WARNING. Gerd Date: Wed, 20 May 2015 21:10:59 +0200 From: extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Request for feature: show wrong roundabouts Could this warning be taken out if "--check-roundabouts" is not given? As my maps are not for cars - I don't mind a roundabout being mapped in the wrong direction... On 4 May 2015 at 16:36, Gerd Petermann wrote: Hi Thorsten, great! So I think I will commit report-driving-side-v1.patch soon. Attached is a patch that should report a warning in LocatorConfig when the ISO code is not known and the driving side is requested. It also adds the evaluation of country-abbr to StyledConverter so that it is possible to work without bounds. The test looks first for the mkgmap:country tag in the road, if that is not set and --country-abbr is set, that the latter value is used to request the driving side from LocatorConfig.xml. Gerd > Date: Mon, 4 May 2015 16:25:35 +0200 > From: ku...@suse.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: 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 ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Named bridges not displaying
Hi Dave,
I agree that the rules to set a "name" are very confusing, esp. when it
comes to roads. I guess one reason is that it took a while to discover
that a map object can have 4 labels,
another point is that we don't try to explain the Garmin format in this
manual, instead we presume that the reader knows the details of the
Garmin format quite well.
Maybe it would help to add a chapter with links to
the corresponding manuals and wiki pages.
If you have the time, please propose improvements, the sources are
almost normal text files.
Reg. your questions:
Why not addabel ?
I thought you want to see the bridge name in the map. If that is the case, you
have
to set mkgmap:label:1 . If you want to be able to find the bridge in address
search,
you can use addlabel without problems.
Why doesn't set name='${bridge:name}' work?
Because it sets the tag name to a new /different value. If it is not followed
by a rule that uses this value to set mkgmap:label:* you will not see a change.
Gerd
From: daveswarth...@gmail.com
Date: Wed, 20 May 2015 12:09:55 -0700
Subject: Re: [mkgmap-dev] Named bridges not displaying
To: gpetermann_muenc...@hotmail.com
Thank you very much. That worked like a charm.
As for the style manual,
4.3.6. nameThis sets the first label of the element but only if it is not
already set. This is a helper action. The sameeffect can be produced with
different notations as it is shown in the following example where all
threelines have the same effect. {name '${name} (${ref})' | '${ref}' |
'${name}'} {add mkgmap:label:1='${name} (${ref})' | '${ref}' | '${name}'}
mkgmap:label:1!=* {set mkgmap:label:1='${name} (${ref})' | '${ref}' | '${name}'}
How one would determine that this is a situation when one must assign a mkgmap
label is beyond me. I could have read that description a thousand times and not
figured out what to do. What's missing is WHY one would use the name directive
in this way. And then, some information about the use of mkgmap:label:1 in
these circumstances would be helpful too.
In scanning the manual I noticed another directive, addlabel which would assign
the next available label level. Why didn't you use that? I'm thinking it's
because you already knew the tags for these two bridges so you knew
mkgmap:label:1 was not being used. But wouldn't addlabel be a "safer" way to go
about this in the general case?
One last question: During my struggles I tried using the set command, {set
name='${bridge:name}' }, to replace the name of the section of highway that
crosses the bridge with the bridge name but it didn't work. Could you venture a
reason for that?
On Wed, May 20, 2015 at 10:02 AM, Gerd Petermann
wrote:
Hi Dave,
the name action has no effect when mkgmap:label:1 is already
set. You may move your rule before those
that use the highway name, or you can use
bridge=* & bridge:name=* {set mkgmap:label:1= '${bridge:name}'; echotags ""}
See style manual section 4.3.6
Gerd
From: daveswarth...@gmail.com
Date: Wed, 20 May 2015 09:49:43 -0700
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Named bridges not displaying
Thanks for all the good effort on the exit_to and destination issues.
Everything is working well for me now.
I discovered another problem that might be simple to fix, or maybe there's
something that I'm doing wrong. There are two named bridges in my current area
but the names do not display on my maps.
I placed this rule in my lines style file:
bridge=* & bridge:name=* {name '${bridge:name}'; echotags ""}
here is the stderr output
221689337 - [highway=tertiary,ref=CR 48,mkgmap:label:2=Lower Smith River Road
(CR 48),bridge=yes,name=Lower Smith River Road,bridge:name=Jack Franz
Bridge,surface=asphalt,mkgmap:street=Lower Smith River Road,mkgmap:label:1=
CR48 Lower Smith River Road,ele=1] 336150197 -
[highway=residential,mkgmap:street=Goodpasture Road,mkgmap:label:1=Goodpasture
Road,covered=yes,bridge=yes,bridge:name=Goodpasture Bridge,name=Goodpasture
Road]
The bridge name does not appear on the compiled maps.
Any ideas or suggestions?
Dave--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] use role=label member to place POI
jHi Gerd, see the error with this binary, I had to use the --going to proceed __ Time started: Wed May 20 23:01:32 BRT 2015 java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.POIGeneratorHook.addPOIsToMPs(POIGen eratorHook.java:388) at uk.me.parabola.mkgmap.reader.osm.POIGeneratorHook.end(POIGeneratorHoo k.java:162) at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingH ooksChain.java:79) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinM apDataSource.java:63) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSour ce.java:129) 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:255) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 ___ Anor C. A. de Souza Concórdia SC 49-8866-3290 Claro49-8808-4963 Vivo49-9975-2560 Tim From: paco.ty...@free.fr Date: Wed, 20 May 2015 16:58:45 +0200 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v1] use role=label member to place POI Hi Gerd, What happens when the relation has both role=label and role=admin_centre ? Le 20 mai 2015 à 16:41, Gerd Petermann a écrit :Hi all, quite a lot of mp-relations have a node member with role=label. The attached patch changes the code for the --add-pois-to-areas option so that the location of this node is used for the generated POI when the name of the node and the name of the relation are equal (like with role=admin_centre) A binary is here: http://files.mkgmap.org.uk/download/268/mkgmap.jar 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Gerd, the problem occurs when there is the administrative boundary relation admin_level = 10. At least in Brazil there is no admin_centre to admin_level 10. When included in relation to tag place the add-poi-to-area create a POI at the center, which I believe would be desired, however, in many relations of this type, this addition doubles the POI when this already exists in the area. I'm not a programmer, but I imagine a rule that when in a boundary relation admin_level = 10, do not create a POI in the center where there is a POI with the same name in the area. Marcio From: Gerd Petermann Sent: Wednesday, May 20, 2015 10:53 AM To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Anor, no, sorry, you probably wanted to point out that mkgmap should treat this case like a node with admin_centre=*. I see that this is only a proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label and it seems not widely used. Any comments from others? Gerd From: gpetermann_muenc...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 15:44:29 +0200 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Anor, interesting, I've just posted a possible explanation for this. Please check if the boundary below is divided as described here: http://gis.19327.n5.nabble.com/Duplicate-cities-tp5845284.html Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Duplicate cities
Hi Gerd, > When you use --add-pois-to-areas mkgmap will generate > a POI based on the existing data, and this POI will have the > tag place=city (for the example), so for each tile we calculate > different coordinates for the city POI. Not only cites but all polygons can get duplicate POIs. Probably cities are worst, because they are easily accessible with search function. > You can solve this particular problem by telling splitter to keep > all administrative boundaries complete, but that will produce > a lot more data in each tile: > --boundary-tags=administrative Looks like the easiest solution, so maybe we can allow for bigger tiles. I think you can save complete multipolygons too. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Suppress Warnings for different Code page
I know this is based on: If the index is created from previously compiled .img files, then the same code page and sorting options (e.g. --code-page, --latin1) must be used as were used to compile the individual map tiles. - but it 's not the way it works. It is rather: If the index is created from previously compiled .img files, then then only content in the same code page and sorting options (e.g. --code-page, --latin1) as indicated in the mkgmap call will be used. Searchable content from wrong codespace previously compiled .img files may be missing or broken (but this does not matter if those .img files have no actual searchable content - e.g. transparent contourlines only maps) On 20 May 2015 at 21:03, Felix Hartmann wrote: > When combinining .img files into a mapset - there is no need to warn about > different codepages if the added maps do not contain anything to search > for. So Warnings of the following types: > > WARNING: input file 7574.img has different code page 1252 > WARNING: input file 7574.img has different charset type 10 > WARNING: input files have different code pages > > > are not needed if you for example add contourlines only maps into a mapset > ofther maps. Could there be a possibility to suppress remove those code > page and charset type warnings? > > > It would make it easier to read my logs for real errors... > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > Floragasse 9/11 > 1040 Wien > Austria - Österreich > -- 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
Re: [mkgmap-dev] Request for feature: show wrong roundabouts
Could this warning be taken out if "--check-roundabouts" is not given? As my maps are not for cars - I don't mind a roundabout being mapped in the wrong direction... On 4 May 2015 at 16:36, Gerd Petermann wrote: > Hi Thorsten, > > great! So I think I will commit report-driving-side-v1.patch soon. > > Attached is a patch that should report a warning in LocatorConfig > when the ISO code is not known and the driving side is requested. > > It also adds the evaluation of country-abbr to StyledConverter > so that it is possible to work without bounds. > The test looks first for the mkgmap:country tag in the road, > if that is not set and --country-abbr is set, that the latter value > is used to request the driving side from LocatorConfig.xml. > > Gerd > > > Date: Mon, 4 May 2015 16:25:35 +0200 > > From: ku...@suse.de > > To: mkgmap-dev@lists.mkgmap.org.uk > > Subject: 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 > > ___ > 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
[mkgmap-dev] Suppress Warnings for different Code page
When combinining .img files into a mapset - there is no need to warn about different codepages if the added maps do not contain anything to search for. So Warnings of the following types: WARNING: input file 7574.img has different code page 1252 WARNING: input file 7574.img has different charset type 10 WARNING: input files have different code pages are not needed if you for example add contourlines only maps into a mapset ofther maps. Could there be a possibility to suppress remove those code page and charset type warnings? It would make it easier to read my logs for real errors... -- 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
Re: [mkgmap-dev] [Patch v1] use role=label member to place POI
Gerd, I don't really have an opinion on which one should be preferred, I was just asking out of curiosity. The first matching means the first in the list of objects linked to the relation, am I right ? I have seen label used in the past, I can't guarantee you that both were set but as usual with OSM, we can't eliminate this combination. Paco Le 20 mai 2015 à 17:07, Gerd Petermann a écrit : > Hi Paco, > > the first one that matches is used. Do you think that one should be prefered? > Do you have a case where both nodes have the same name as the relation itself? > > Gerd > > From: paco.ty...@free.fr > Date: Wed, 20 May 2015 16:58:45 +0200 > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] [Patch v1] use role=label member to place POI > > Hi Gerd, > > What happens when the relation has both role=label and role=admin_centre ? > > > Le 20 mai 2015 à 16:41, Gerd Petermann a > écrit : > > Hi all, > > quite a lot of mp-relations have a node member with role=label. > > The attached patch changes the code for the --add-pois-to-areas option > so that the location of this node is used for the generated POI > when the name of the node and the name of the relation are equal > (like with role=admin_centre) > > A binary is here: > http://files.mkgmap.org.uk/download/268/mkgmap.jar > > Gerd > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > ___ mkgmap-dev mailing > listmkgmap-...@lists.mkgmap.org.ukhttp://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
[mkgmap-dev] Named bridges not displaying
Thanks for all the good effort on the exit_to and destination issues.
Everything is working well for me now.
I discovered another problem that might be simple to fix, or maybe there's
something that I'm doing wrong. There are two named bridges in my current
area but the names do not display on my maps.
I placed this rule in my lines style file:
bridge=* & bridge:name=* {name '${bridge:name}'; echotags ""}
here is the stderr output
221689337 - [highway=tertiary,ref=CR 48,mkgmap:label:2=Lower Smith River
Road (CR 48),bridge=yes,name=Lower Smith River Road,bridge:name=Jack Franz
Bridge,surface=asphalt,mkgmap:street=Lower Smith River Road,mkgmap:label:1=
CR48 Lower Smith River Road,ele=1]
336150197 - [highway=residential,mkgmap:street=Goodpasture
Road,mkgmap:label:1=Goodpasture
Road,covered=yes,bridge=yes,bridge:name=Goodpasture Bridge,name=Goodpasture
Road]
The bridge name does not appear on the compiled maps.
Any ideas or suggestions?
Dave
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] use role=label member to place POI
Hi Paco, the first one that matches is used. Do you think that one should be prefered? Do you have a case where both nodes have the same name as the relation itself? Gerd From: paco.ty...@free.fr Date: Wed, 20 May 2015 16:58:45 +0200 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v1] use role=label member to place POI Hi Gerd, What happens when the relation has both role=label and role=admin_centre ? Le 20 mai 2015 à 16:41, Gerd Petermann a écrit :Hi all, quite a lot of mp-relations have a node member with role=label. The attached patch changes the code for the --add-pois-to-areas option so that the location of this node is used for the generated POI when the name of the node and the name of the relation are equal (like with role=admin_centre) A binary is here: http://files.mkgmap.org.uk/download/268/mkgmap.jar 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] use role=label member to place POI
Hi Gerd, What happens when the relation has both role=label and role=admin_centre ? Le 20 mai 2015 à 16:41, Gerd Petermann a écrit : > Hi all, > > quite a lot of mp-relations have a node member with role=label. > > The attached patch changes the code for the --add-pois-to-areas option > so that the location of this node is used for the generated POI > when the name of the node and the name of the relation are equal > (like with role=admin_centre) > > A binary is here: > http://files.mkgmap.org.uk/download/268/mkgmap.jar > > 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
[mkgmap-dev] [Patch v1] use role=label member to place POI
Hi all, quite a lot of mp-relations have a node member with role=label. The attached patch changes the code for the --add-pois-to-areas option so that the location of this node is used for the generated POI when the name of the node and the name of the relation are equal (like with role=admin_centre) A binary is here: http://files.mkgmap.org.uk/download/268/mkgmap.jar Gerd use-label-node-v1.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi gerd In this case there is no admin because it is inside the admin 8. Ali this case not to duplicate the POI only excluded the key place ___ Anor C. A. de Souza Concórdia SC From: gpetermann_muenc...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 15:53:50 +0200 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Anor, no, sorry, you probably wanted to point out that mkgmap should treat this case like a node with admin_centre=*. I see that this is only a proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label and it seems not widely used. Any comments from others? Gerd From: gpetermann_muenc...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 15:44:29 +0200 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Anor, interesting, I've just posted a possible explanation for this. Please check if the boundary below is divided as described here: http://gis.19327.n5.nabble.com/Duplicate-cities-tp5845284.html Gerd From: anorcar...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 10:38:06 -0300 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Gerd I see you have more case doubling the POI in admin_level 10 when have included place in the relationship. This makes 2 POI ___ Anor C. A. de Souza Concórdia SC > From: s...@mkgmap.org.uk > To: mkgmap-...@lists.mkgmap.org.uk > Date: Sun, 10 May 2015 06:30:59 +0100 > Subject: [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create > duplicate POI > > > Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 > > admin_centre-v1.patch: avoid to create duplicate POI > > It implements the following: > When POIGeneratorHook creates a POI for a type=boundary relation > with boundary=administrative it searches for a role=admin_centre member > in that relation. > If one is found, the generated POI will use the coordinates of this member. > > I see no easy way to compare the tags of the existing > node with those of the generated POI, so > as a second step, StyledConverter detects when a POI > with the same type and name (or empty name) is created at the > same Garmin coordinates (after style processing) > If that is true, the latter one is ignored and an info message is logged. > > Maybe for certain types this should be changed to check for a radius > rather than equality, but that would require complex configuration. > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Anor, no, sorry, you probably wanted to point out that mkgmap should treat this case like a node with admin_centre=*. I see that this is only a proposal: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Label and it seems not widely used. Any comments from others? Gerd From: gpetermann_muenc...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 15:44:29 +0200 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Anor, interesting, I've just posted a possible explanation for this. Please check if the boundary below is divided as described here: http://gis.19327.n5.nabble.com/Duplicate-cities-tp5845284.html Gerd From: anorcar...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 10:38:06 -0300 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Gerd I see you have more case doubling the POI in admin_level 10 when have included place in the relationship. This makes 2 POI ___ Anor C. A. de Souza Concórdia SC > From: s...@mkgmap.org.uk > To: mkgmap-...@lists.mkgmap.org.uk > Date: Sun, 10 May 2015 06:30:59 +0100 > Subject: [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create > duplicate POI > > > Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 > > admin_centre-v1.patch: avoid to create duplicate POI > > It implements the following: > When POIGeneratorHook creates a POI for a type=boundary relation > with boundary=administrative it searches for a role=admin_centre member > in that relation. > If one is found, the generated POI will use the coordinates of this member. > > I see no easy way to compare the tags of the existing > node with those of the generated POI, so > as a second step, StyledConverter detects when a POI > with the same type and name (or empty name) is created at the > same Garmin coordinates (after style processing) > If that is true, the latter one is ignored and an info message is logged. > > Maybe for certain types this should be changed to check for a radius > rather than equality, but that would require complex configuration. > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ 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
Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Anor, interesting, I've just posted a possible explanation for this. Please check if the boundary below is divided as described here: http://gis.19327.n5.nabble.com/Duplicate-cities-tp5845284.html Gerd From: anorcar...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 10:38:06 -0300 Subject: Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI Hi Gerd I see you have more case doubling the POI in admin_level 10 when have included place in the relationship. This makes 2 POI ___ Anor C. A. de Souza Concórdia SC > From: s...@mkgmap.org.uk > To: mkgmap-...@lists.mkgmap.org.uk > Date: Sun, 10 May 2015 06:30:59 +0100 > Subject: [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create > duplicate POI > > > Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 > > admin_centre-v1.patch: avoid to create duplicate POI > > It implements the following: > When POIGeneratorHook creates a POI for a type=boundary relation > with boundary=administrative it searches for a role=admin_centre member > in that relation. > If one is found, the generated POI will use the coordinates of this member. > > I see no easy way to compare the tags of the existing > node with those of the generated POI, so > as a second step, StyledConverter detects when a POI > with the same type and name (or empty name) is created at the > same Garmin coordinates (after style processing) > If that is true, the latter one is ignored and an info message is logged. > > Maybe for certain types this should be changed to check for a radius > rather than equality, but that would require complex configuration. > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ 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] Duplicate cities
Hi all, I've noticed the following problem with boundary relations (type=boundary, boundary=administrative), e.g. http://www.openstreetmap.org/relation/170953 is cut into pieces with the attached areas.list By default, splitter will not keep them complete, and it is likely that this relation appears in more than one tile. When you use --add-pois-to-areas mkgmap will generate a POI based on the existing data, and this POI will have the tag place=city (for the example), so for each tile we calculate different coordinates for the city POI. I guess this happens with other relations as well. You can solve this particular problem by telling splitter to keep all administrative boundaries complete, but that will produce a lot more data in each tile: --boundary-tags=administrative So, I see two possible solutions: 1) change splitter so that it keeps mp-relations complete when they have a tag like place. A new option could specify a list of those tags . 2) change mkgmap so that it doesn't generate a POI for mp-relations with incomplete outer ways. What do you think? Gerd # List of areas # Generated Wed May 20 15:30:28 CEST 2015 # 63240001: 1867776,-3721216 to 2101248,-3590144 # : 40.078125,-79.848633 to 45.087891,-77.036133 63240002: 2021376,-3590144 to 2101248,-3287040 # : 43.374023,-77.036133 to 45.087891,-70.532227 63240003: 1867776,-3436544 to 2021376,-3287040 # : 40.078125,-73.740234 to 43.374023,-70.532227 63240004: 1867776,-3446784 to 1896448,-3436544 # : 40.078125,-73.959961 to 40.693359,-73.740234 63240005: 1867776,-3590144 to 1896448,-3446784 # : 40.078125,-77.036133 to 40.693359,-73.959961 63240006: 1896448,-3590144 to 2021376,-3493888 # : 40.693359,-77.036133 to 43.374023,-74.970703 63240007: 1906688,-3493888 to 1949696,-3436544 # : 40.913086,-74.970703 to 41.835938,-73.740234 63240008: 1949696,-3493888 to 2021376,-3436544 # : 41.835938,-74.970703 to 43.374023,-73.740234 63240009: 1896448,-3493888 to 1906688,-3442688 # : 40.693359,-74.970703 to 40.913086,-73.872070 63240010: 1896448,-3442688 to 1906688,-3436544 # : 40.693359,-73.872070 to 40.913086,-73.740234 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create duplicate POI
Hi Gerd I see you have more case doubling the POI in admin_level 10 when have included place in the relationship. This makes 2 POI ___ Anor C. A. de Souza Concórdia SC > From: s...@mkgmap.org.uk > To: mkgmap-...@lists.mkgmap.org.uk > Date: Sun, 10 May 2015 06:30:59 +0100 > Subject: [mkgmap-svn] Commit: r3573: admin_centre-v1.patch: avoid to create > duplicate POI > > > Version mkgmap-r3573 was committed by gerd on Sun, 10 May 2015 > > admin_centre-v1.patch: avoid to create duplicate POI > > It implements the following: > When POIGeneratorHook creates a POI for a type=boundary relation > with boundary=administrative it searches for a role=admin_centre member > in that relation. > If one is found, the generated POI will use the coordinates of this member. > > I see no easy way to compare the tags of the existing > node with those of the generated POI, so > as a second step, StyledConverter detects when a POI > with the same type and name (or empty name) is created at the > same Garmin coordinates (after style processing) > If that is true, the latter one is ignored and an info message is logged. > > Maybe for certain types this should be changed to check for a radius > rather than equality, but that would require complex configuration. > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] levels in style aren't processed correctly
Hi Andrzej > I don't understand this. If you have no --levels option then the > default should be used, which has a maximum of 4. Looks like there is no defaults now, or maybe only level 0 gets a default resolution. There is a default for levels: DEFAULT_LEVELS = "0:24, 1:22, 2:20, 3:18, 4:16" There is not a default for overview-levels, although an overview level is constructed based on the highest level in 'levels'. > What do you think that the message text should be? Maybe something like "'level 1' is used in style while its resolution is not defined in option 'levels=' nor "overview-levels=". OK. > What are the conditions to cause this error? My previous analysis was wrong. This is what I'm doing: - I have modified default style changing some "resolution xx" to "level 0", "level 1" or "level 2". - I have commented "levels=" and "overview-levels=" in "options" file. Now I run compilation with following command line options: 1) --levels=0:22,1:21,2:20 --gmapsupp --no-tdbfile 2) --levels=0:22,1:21 --gmapsupp --no-tdbfile 3) --levels=0:22,1:21 --overview-levels=4:16 --gmapsupp --no-tdbfile Compilation 1) goes correctly. Compilation 2) ends with an error. Compilation 3) creates a map. Oh I see now. In case 2 the highest level is 1, whereas in 3) the max level is 2, since the normal and overview levels are combined. I can change this so that a level 2 would translate to the resolution of the level less than or equal to it. ..Steve ___ 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 Thorsten, okay, got the same results. The interesting point here is that the code fills lists in the LBL file, but I don't extra code that would write them to the global index as we do with cities. Anyway, too much work for me, I'll concentrate on the branch for now. Gerd Thorsten Kukuk wrote > 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@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/question-reg-exits-tp5845107p5845255.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
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] Address search Croatia
Hi,
On Wed, May 20, Thorsten Kukuk wrote:
>
> Hi,
>
> the problem is that there are no rules for Croatia in
> inc/address.
And even worse: the admin_level boundaries are a nightmare, most are
incomplete. And for cities it looks like they don't use admin_level
boundaries, but simple ways like this one:
https://www.openstreetmap.org/way/177736372
I don't understand enough how the addresses in Croatia are working
to implement some enhancements for inc/address, but it looks to me,
at first the croatia mapper need to fix the admin_level data.
Nevertheless, you could try this patch. I haven't tested it yet,
there are nearly no address informations in Croatia. But looking
at the OSM data for Zagreb, it should at least help there.
And I'm not sure about the order of this three lines ...
--- inc/address 6 May 2015 09:18:21 - 1.9
+++ inc/address 20 May 2015 09:23:23 -
@@ -42,6 +42,9 @@
mkgmap:country=FIN & mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
+mkgmap:country=HRV & mkgmap:city!=* & mkgmap:admin_level6='Grad Zagreb' { set
mkgmap:city='Zagreb' }
+mkgmap:country=HRV & mkgmap:city!=* & mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7|subst:Grad =>}' }
+mkgmap:country=HRV & mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=ISL & mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=ITA & mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=LUX & mkgmap:city!=* & mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
Thorsten
> Thorsten
>
> On Wed, May 20, thesurve...@wolke7.net wrote:
>
> > Hi all,
> >
> >
> >
> > I've started to create a map of Croatia.
> >
> > I've done and all seemed to work fine, but when I try to find an
> > address it doesn't work.
> >
> >
> >
> > I even don't find major cities like "Split" in address
> > search.
> >
> > I'm using my own style but I checked with default style - same
> > result. For other countries it works.
> >
> > I'm using boundary files from 2015-02-06.
> >
> >
> >
> > Can someone check in his maps if it works for you? Any hints where to
> > check?
> >
> >
> >
> > Thanks,
> >
> > Gert
> >
> >
> >
> >
>
> > ___
> > 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, 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, 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 Thorsten,>
> Where/how do you search for them?
>
> I have:
> highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' }
> highway=motorway_junction [0x2000 level 2]
> highway=services[0x210f level 2 default_name
> 'Services']
>
> In my rules and can search for them in MapSource.
How ?
What category / sub category is it?
Gerd
___
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] Address search Croatia
Hi Gert, I just tried with the housenumber2 branch. I can find Split in cities as well as in address search. With the trunk version I find fewer adresses, but the search for e.g. Bihacka 2 in Split works also. Gerd From: thesurve...@wolke7.net To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 20 May 2015 10:08:08 +0200 Subject: [mkgmap-dev] Address search Croatia Hi all, I've started to create a map of Croatia. I've done and all seemed to work fine, but when I try to find an address it doesn't work. I even don't find major cities like "Split" in address search. I'm using my own style but I checked with default style - same result. For other countries it works. I'm using boundary files from 2015-02-06. Can someone check in his maps if it works for you? Any hints where to check? Thanks, Gert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question reg. exits
Hi Gerd,
On Wed, May 20, Gerd Petermann wrote:
> I played a bit with the style rules and found that this rule
> highway=motorway_junction & exit_to=* { set exit:to='${exit_to}'; set
> exit:facility='3,N,7,blabla'}
>
> produces some extra data in the properties of each exit POI.
I played with it yesterday, too, but was not succesful. At least
MapSource didn't show this entries.
But to be usefull I think we would need a lot of help from mkgmap.
For exit:to and exit:facilities.
For exit:to we would need the direction (N,S,O,W,...) and for
exit:facilities we need to look, what other interesting POI are there.
> I was not able to make these exits searchable in MapSource or Basecamp.
Where/how do you search for them?
I have:
highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' }
highway=motorway_junction [0x2000 level 2]
highway=services[0x210f level 2 default_name
'Services']
In my rules and can search for them in MapSource.
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.
Thorsten
> I assume that we have to set a special bit in one of the headers to make that
> work.
>
> Gerd
>
>
>
> > Date: Tue, 19 May 2015 10:43:13 +0200
> > From: ku...@suse.de
> > To: mkgmap-dev@lists.mkgmap.org.uk
> > Subject: 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
>
>
> ___
> 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, 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 Thorsten,
I followed the discussions and it seems that this
feature was somehow forgotten, not sure why.
I played a bit with the style rules and found that this rule
highway=motorway_junction & exit_to=* { set exit:to='${exit_to}'; set
exit:facility='3,N,7,blabla'}
produces some extra data in the properties of each exit POI.
The meaning of the exit:facility stuff is explained in the cgpsmapper manual
http://cgpsmapper.com/download/cGPSmapper-UsrMan-v02.5.pdf
on page 105 + 106.
I was not able to make these exits searchable in MapSource or Basecamp.
I assume that we have to set a special bit in one of the headers to make that
work.
Gerd
> Date: Tue, 19 May 2015 10:43:13 +0200
> From: ku...@suse.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search Croatia
Hi, the problem is that there are no rules for Croatia in inc/address. Thorsten On Wed, May 20, thesurve...@wolke7.net wrote: > Hi all, > > > > I've started to create a map of Croatia. > > I've done and all seemed to work fine, but when I try to find an > address it doesn't work. > > > > I even don't find major cities like "Split" in address > search. > > I'm using my own style but I checked with default style - same > result. For other countries it works. > > I'm using boundary files from 2015-02-06. > > > > Can someone check in his maps if it works for you? Any hints where to > check? > > > > Thanks, > > Gert > > > > > ___ > 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, 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] Address search Croatia
Hi all, I've started to create a map of Croatia. I've done and all seemed to work fine, but when I try to find an address it doesn't work. I even don't find major cities like "Split" in address search. I'm using my own style but I checked with default style - same result. For other countries it works. I'm using boundary files from 2015-02-06. Can someone check in his maps if it works for you? Any hints where to check? Thanks, Gert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
