logo separator

[mkgmap-dev] Question reg. precompiled bounds

From WanMil wmgcnfg at web.de on Wed Jan 25 21:17:33 GMT 2012

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




More information about the mkgmap-dev mailing list