Question reg. precompiled bounds

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Question reg. precompiled bounds

Gerd Petermann
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
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

railrun
Hi Gerd,

I think this is the same thing I mentioned here:

//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-tp7217885p7217885.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Gerd Petermann
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: [hidden email]
Date: Tue, 24 Jan 2012 00:23:03 +0100
To: [hidden email]
Subject: Re: [mkgmap-dev] Question reg. precompiled bounds

Hi Gerd,

I think this is the same thing I mentioned here:

//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-tp7217885p7217885.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_______________________________________________ mkgmap-dev mailing list [hidden email] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

WanMil
In reply to this post by Gerd Petermann
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-tp7217885p7217885.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Gerd Petermann
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: [hidden email]
> To: [hidden email]
> 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-tp7217885p7217885.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > _______________________________________________
> > mkgmap-dev mailing list
> > [hidden email]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

WanMil
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: [hidden email]
>  > To: [hidden email]
>  > 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-tp7217885p7217885.html
>  > > Sent from the Mkgmap Development mailing list archive at Nabble.com.
>  > > _______________________________________________
>  > > mkgmap-dev mailing list
>  > > [hidden email]
>  > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>  >
>  > _______________________________________________
>  > mkgmap-dev mailing list
>  > [hidden email]
>  > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

osm-8
In reply to this post by WanMil
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Gerd Petermann
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: [hidden email]
To: [hidden email]
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 [hidden email] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Thorsten Kukuk
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Gerd Petermann
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: [hidden email]

> To: [hidden email]
> 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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Thorsten Kukuk
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: [hidden email]
> > To: [hidden email]
> > 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
> > [hidden email]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>      
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Gerd Petermann
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: [hidden email]
> To: [hidden email]
> 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: [hidden email]
> > > To: [hidden email]
> > > 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
> > > [hidden email]
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > _______________________________________________
> > mkgmap-dev mailing list
> > [hidden email]
> > 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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

WanMil
In reply to this post by Thorsten Kukuk
> 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
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Apollinaris Schöll

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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

WanMil
>
> 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
>> [hidden email]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Thorsten Kukuk
In reply to this post by WanMil
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)
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

Apollinaris Schöll
In reply to this post by WanMil

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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Question reg. precompiled bounds

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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev