[mkgmap-dev] superfluous country specific rules in inc/address?

Mon Jun 8 05:31:26 BST 2015

Hi Stephen,

I still have no idea what you mean, but feel free to try it out.

Gerd

Date: Mon, 8 Jun 2015 13:40:49 +1000
From: steve.sgalowski at gmail.com
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] superfluous country specific rules in inc/address?

gerd the reason behind my thinking was if you do in order of country , state, region , suburbyou end up with a less of a download on pc e.g. with basecamp and birdseye , imagery , if you do a 120 m pic it takes a while to download , but if you do a step down from  high quality , big area , to high quakity small area , it does not take a lot of  downloading power .
is this the same in the osm mapping .eg  you do a level 9 for suburb , and it takes a lot to produce , but a 5-9 does not ?
Stephen 

On Sun, Jun 7, 2015 at 2:15 PM, Gerd Petermann <gpetermann_muenchen at hotmail.com> wrote:

Hi all,

it seems that I have to explain a few more details.

The inc/address file contains rules which set the tags
like mkgmap:country, mkgmap:region, mkgmap:city and 
so on. 
These tags are used in two different ways:
1) for housenumber processing
2) to fill the corresponding fields of POIs 

With my initial post I just wanted to point out that we have a lot
of redundant rules, and the patch posted here
http://gis.19327.n5.nabble.com/Patch-v1-simplify-address-rules-tp5847326.html
shows which rules I mean.

In the meantime Minko suggested to modify the rule for BEL instead of removing it.

The general rules implemented in the file are:
mkgmap:admin_level2 : mkgmap:country (this is the 3 character ISO code, e.g. GER for Germany)
mkgmap:admin_level6,5,4,3  : mkgmap:region (meaning depends on country)
mkgmap:admin_level8,7,9,10 : mkgmap:city

A rather simple test to find out if the implemented rules are good is
to compare addr:city with mkgmap:city.
Add a line like this at the end of inc/address:
mkgmap:city!=* & addr:city!=* & addr:city != ${mkgmap:city} { echotags "city name?" }

and check the messages. When all rules are OK and the boundary file is up to date
(and also OK) only a few messages should be printed, most of them showing different spelling
of the same name.

If you see many lines where the names in mkgmap:city and addr:city are totally different 
this is a hint that either the rules are not OK or that boundaries are missing/wrong.

Gerd

From: gdt at ir.bbn.com
To: steve.sgalowski at gmail.com
Date: Sat, 6 Jun 2015 20:21:05 -0400
CC: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] superfluous country specific rules in inc/address?

Steve Sgalowski <steve.sgalowski at gmail.com> writes:

> mkgmap:country  admin level 5
>
> then mkgmap:state admin level 6
> mkgmap:region admin level 7
> postcode sdmin level 8
> suburb  level 9, 10

My quick reaction is that which admin_level corresponds to which parts
of an address varies by region.  In my part of the US, state is level4,
city/town is level8, and that's really all there is in address.
Whether a (legal) city/town is "suburb", "city", "town", "village",
etc. is based on size and relationship to larger entities.

Around me only two cities have admin_level 10 boundaries.  One calls
them neighborhoods or villages, not suburbs.  Sometimes they show up in
postal addresses.

So really I wonder if this means that the address component rules should
be encoded on the boundary, something like "addresses within this
polygon inherit name_component_foo=bar".

I am leaning to having addresses have everything (in the US) below state
explicit, to avoid this.

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  

_______________________________________________

mkgmap-dev mailing list

mkgmap-dev at lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150608/bd793034/attachment-0001.html>