Hi, some of the precompiled bounds contain quite a lot of buildings with a postal_code tag, e.g. http://www.openstreetmap.org/browse/way/25587396 or http://www.openstreetmap.org/browse/way/60792963 Is this info really needed in the location hook? It seems to slow down the creation of the quadtree. Ciao, Gerd -- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-precompiled-bounds-tp7217885p72... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I think this is the same thing I mentioned here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013560.html //Martin Am 23.01.2012 um 22:43 schrieb GerdP:
Hi,
some of the precompiled bounds contain quite a lot of buildings with a postal_code tag, e.g. http://www.openstreetmap.org/browse/way/25587396 or http://www.openstreetmap.org/browse/way/60792963
Is this info really needed in the location hook? It seems to slow down the creation of the quadtree.
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-precompiled-bounds-tp7217885p72... 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
Hi Martin, yes, when I read your post I was not so sure if we need the streets, they might also be part of relations. I think I can easily implement a filter in preparer that removes all closed ways with a postal_code lying inside of a boundary with the same postal_code value. I think this should not have any side effect within the LocationHook of mkgmap. Ciao, Gerd From: mkmap@snailrun.de Date: Tue, 24 Jan 2012 00:23:03 +0100 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds Hi Gerd, I think this is the same thing I mentioned here:http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013560.html //Martin Am 23.01.2012 um 22:43 schrieb GerdP:Hi, some of the precompiled bounds contain quite a lot of buildings with a postal_code tag, e.g. http://www.openstreetmap.org/browse/way/25587396 or http://www.openstreetmap.org/browse/way/60792963 Is this info really needed in the location hook? It seems to slow down the creation of the quadtree. Ciao, Gerd -- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-precompiled-bounds-tp7217885p72... 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, it depends on how exact you want to be. In most cases you won't require building with a postal_code tag. But if the building contains a POI without a postal_code you might need it. I know this example is a bit too meticulous but it shows the general problem we have unless there is a commonly used tagging for postal_code areas. WanMil
Hi,
some of the precompiled bounds contain quite a lot of buildings with a postal_code tag, e.g. http://www.openstreetmap.org/browse/way/25587396 or http://www.openstreetmap.org/browse/way/60792963
Is this info really needed in the location hook? It seems to slow down the creation of the quadtree.
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-precompiled-bounds-tp7217885p72... 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
Hi WanMil, okay, I agree that we might need the data. What do you think about removing it when it lies in a boundary that has the same postal_code? Gerd
Date: Tue, 24 Jan 2012 22:22:19 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
Hi Gerd,
it depends on how exact you want to be. In most cases you won't require building with a postal_code tag. But if the building contains a POI without a postal_code you might need it. I know this example is a bit too meticulous but it shows the general problem we have unless there is a commonly used tagging for postal_code areas.
WanMil
Hi,
some of the precompiled bounds contain quite a lot of buildings with a postal_code tag, e.g. http://www.openstreetmap.org/browse/way/25587396 or http://www.openstreetmap.org/browse/way/60792963
Is this info really needed in the location hook? It seems to slow down the creation of the quadtree.
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-precompiled-bounds-tp7217885p72... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, of course it is completely correct (and desired) to remove duplicate data :-) WanMil
Hi WanMil,
okay, I agree that we might need the data. What do you think about removing it when it lies in a boundary that has the same postal_code?
Gerd
Date: Tue, 24 Jan 2012 22:22:19 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
Hi Gerd,
it depends on how exact you want to be. In most cases you won't require building with a postal_code tag. But if the building contains a POI without a postal_code you might need it. I know this example is a bit too meticulous but it shows the general problem we have unless there is a commonly used tagging for postal_code areas.
WanMil
Hi,
some of the precompiled bounds contain quite a lot of buildings with a postal_code tag, e.g. http://www.openstreetmap.org/browse/way/25587396 or http://www.openstreetmap.org/browse/way/60792963
Is this info really needed in the location hook? It seems to slow down the creation of the quadtree.
Ciao, Gerd
-- View this message in context: http://gis.638310.n2.nabble.com/Question-reg-precompiled-bounds-tp7217885p72... 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
_______________________________________________ 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
On the other hand in Germany there are some companies with an own postal_code. But this postal_code you wont use for navigation, just for writing letters. Henning
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right? Gerd Date: Wed, 25 Jan 2012 00:59:45 +0100 From: osm@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds On the other hand in Germany there are some companies with an own postal_code. But this postal_code you wont use for navigation, just for writing letters. Henning _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have: mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' } The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten, I agree, it should be switched. One correction: LocationHook may add the tag mkgmap:postcode, not mkgmap:postal_code. ciao, Gerd
Date: Wed, 25 Jan 2012 08:57:37 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have:
mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style.
Thorsten
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Wed, Jan 25, Gerd Petermann wrote:
Hi Thorsten,
I agree, it should be switched. One correction: LocationHook may add the tag mkgmap:postcode, not mkgmap:postal_code.
Sorry, I don't understand. mkgmap:postcode is the variable mkgmap initializes with the value from the data, mkgmap:postal_code is the value mkgmap uses later for the address. Thorsten
Date: Wed, 25 Jan 2012 08:57:37 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have:
mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style.
Thorsten
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (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, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Thorsten, your understanding is correct, I wanted to correct my own error in the previous post. Gerd
Date: Wed, 25 Jan 2012 09:15:07 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
On Wed, Jan 25, Gerd Petermann wrote:
Hi Thorsten,
I agree, it should be switched. One correction: LocationHook may add the tag mkgmap:postcode, not mkgmap:postal_code.
Sorry, I don't understand.
mkgmap:postcode is the variable mkgmap initializes with the value from the data, mkgmap:postal_code is the value mkgmap uses later for the address.
Thorsten
Date: Wed, 25 Jan 2012 08:57:37 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Question reg. precompiled bounds
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have:
mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style.
Thorsten
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (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, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have:
mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=*& addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style.
Do you have an example where this would improve the postal code assignment? From my point of view it is better to believe the postal code information from the boundaries. One simple reason for this: A postal_code relation catches all nodes and ways and it has to be tagged once. In constrast you have N elements all tagged individual. The chances are much higher that there are one or more typo errors in the elements than there is one in the relation. Anyhow postal_code relations need to be better maintained in the OSM database. WanMil
Thorsten
On Jan 25, 2012, at 9:52 AM, WanMil wrote:
A postal_code relation catches all nodes and ways and it has to be tagged once. In constrast you have N elements all tagged individual. The chances are much higher that there are one or more typo errors in the elements than there is one in the relation.
In theory this is the best
Anyhow postal_code relations need to be better maintained in the OSM database.
relations are constantly broken in OSM and practically this doesn't work so well. having individual tags provides redundancy and can be used to verify consistency of the relation.
WanMil
Thorsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Jan 25, 2012, at 9:52 AM, WanMil wrote:
A postal_code relation catches all nodes and ways and it has to be tagged once. In constrast you have N elements all tagged individual. The chances are much higher that there are one or more typo errors in the elements than there is one in the relation.
In theory this is the best
Anyhow postal_code relations need to be better maintained in the OSM database.
relations are constantly broken in OSM and practically this doesn't work so well. having individual tags provides redundancy and can be used to verify consistency of the relation.
mkgmap is not a consistency checker. That's the purpose of other apps. We have to decide for one source (or better for an order of sources). So if you don't trust the postal_code relations it should not be integrated into the precompiled bounds. That would be ok for me. But I think the other way round (first use the tags of elements and then use the postal_code relations) does not really make sense for me. Either trust the relation or not. WanMil
WanMil
Thorsten
_______________________________________________ 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
On Jan 25, 2012, at 10:17 AM, WanMil wrote:
relations are constantly broken in OSM and practically this doesn't work so well. having individual tags provides redundancy and can be used to verify consistency of the relation.
mkgmap is not a consistency checker. That's the purpose of other apps. We have to decide for one source (or better for an order of sources). So if you don't trust the postal_code relations it should not be integrated into the precompiled bounds. That would be ok for me.
that's the tricky part. trusting anything in OSM data is hard. in one place there will be relations in others they don't exist at all. and if they exist they can be wrong
But I think the other way round (first use the tags of elements and then use the postal_code relations) does not really make sense for me. Either trust the relation or not.
it makes as much sense the other way round. If individual mappers created elements then I would trust it a lot more than a relation created by one or two. or coming from a bad import. But data doesn't have a label telling anything about quality. So it could be totally the other way round. individual elements are wrong because of a massive copy paste error done by armchair mappers. So if you are going to implement any of this it's always good as long as there are options to disable it if it doesn't work in an area. In the longterm a tool like mkgmap helps to show an example how things work if the data in OSM is good. This can help to streamline mapping practices.
WanMil
Am 25.01.2012 19:59, schrieb Apollinaris Schoell:
On Jan 25, 2012, at 10:17 AM, WanMil wrote:
relations are constantly broken in OSM and practically this doesn't work so well. having individual tags provides redundancy and can be used to verify consistency of the relation.
mkgmap is not a consistency checker. That's the purpose of other apps. We have to decide for one source (or better for an order of sources). So if you don't trust the postal_code relations it should not be integrated into the precompiled bounds. That would be ok for me.
that's the tricky part. trusting anything in OSM data is hard. in one place there will be relations in others they don't exist at all. and if they exist they can be wrong
But I think the other way round (first use the tags of elements and then use the postal_code relations) does not really make sense for me. Either trust the relation or not.
it makes as much sense the other way round. If individual mappers created elements then I would trust it a lot more than a relation created by one or two. or coming from a bad import. But data doesn't have a label telling anything about quality. So it could be totally the other way round. individual elements are wrong because of a massive copy paste error done by armchair mappers.
So if you are going to implement any of this it's always good as long as there are options to disable it if it doesn't work in an area.
That's already possible using the style system. Just add a country rule before the relation postal code rule to use that only in Germany: mkgmap:country=DEU & mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } Sounds like a good idea to use country based rules. WanMil
In the longterm a tool like mkgmap helps to show an example how things work if the data in OSM is good. This can help to streamline mapping practices.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Wed, Jan 25, WanMil wrote:
On Wed, Jan 25, Gerd Petermann wrote:
Yes, but that shouldn't matter in the LocationHook. The LocationHook just adds tags like mkgmap:postal_code to the nodes that form such a building, and I guess that persons who are interested in postal codes will use coresponding lines in their styles to analyse mkgmnap:postal_code AND e.g. addr:postcode. Right?
I think yes ;) At least most styles have:
mkgmap:postal_code!=*& mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' } mkgmap:postal_code!=*& addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
The only question is: should we assume mkgmap:postcode is more correct than addr:postcode? I think the order should be switched in the default style.
Do you have an example where this would improve the postal code assignment? From my point of view it is better to believe the postal code information from the boundaries. One simple reason for this:
A postal_code relation catches all nodes and ways and it has to be tagged once. In constrast you have N elements all tagged individual. The chances are much higher that there are one or more typo errors in the elements than there is one in the relation.
Let's say it this way: I trust the elements much more than the postal_code boundaries in my region. There are two reasons: - in my region nearly all postal_code boundaries are tagged with a fixme: boundaries are guessed and needs to be confirmed. I don't know if the fixme tags are still valid or not. But at least in the office, which is on a postal_code border, they don't really fit with the official addresses. - every second week somebody breaks several postcal_codes, because they split/merge ways and don't care about the relations using this ways. So in my opinion address nodes are more reliable if they exist. While I'm strictly against removing the postcal_codes from the precompiled boundaries: Far too many addresses are missing or incomplete, and here we can use the postal_code from the boundaries if they are currently not broken. But in the end: I don't care much what is in the default style, since everybody can modify his own style how it fits best for him. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (7)
-
Apollinaris Schoell -
Gerd Petermann -
GerdP
-
Henning Scholland -
Martin -
Thorsten Kukuk -
WanMil