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

Mon Jun 8 04:40:49 BST 2015

gerd
the reason behind my thinking was
if you do in order of country , state, region , suburb
you 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150608/e4fdf760/attachment.html>