logo separator

[mkgmap-dev] change inc/address to be a standalone ?

From Gerd Petermann gpetermann_muenchen at hotmail.com on Thu Apr 16 08:48:25 BST 2015

Hi Thorsten,

okay, got it. Did not think about mkgmap:street
and even the default style has to use this trick.

Sorry for the noise.

I think what I was looking for is a set of rules
which depend only on the tags created by the LocationHook.

After the latest news regarding the img format 
I try to change the --housenumber code to group
roads and houses by city/region/country (and maybe also
zip code), so I was looking for an efficient way to 
calculate these values based on the coords of a road point,
but probably the only relavant data is in the houses near 
the road, so we just have to make sure that each element
with addr:housenumber has the relavent tags.

Gerd



> Date: Thu, 16 Apr 2015 09:28:52 +0200
> From: kukuk at suse.de
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
> 
> On Thu, Apr 16, Gerd Petermann wrote:
> 
> > Hi Thorsten,
> > 
> > okay, I think I understand now. You don't use
> > any of the possible tricks in your style, but
> > you don't want to loose the possibility to do it. 
> > Right?
> 
> No, I already use some of the tricks to prevent that
> inc/address set mkgmap:street is set wrongly due to bad
> tagging.
> I can workaround them, but yes, I don't want to loose
> the possibility to fix them.
> 
>   Thorsten
> 
> > I think that is a good point against my proposal.
> > 
> > Gerd
> > 
> > 
> > > Date: Thu, 16 Apr 2015 09:08:22 +0200
> > > From: kukuk at suse.de
> > > To: mkgmap-dev at lists.mkgmap.org.uk
> > > Subject: Re: [mkgmap-dev] change inc/address to be a standalone ?
> > > 
> > > On Thu, Apr 16, Gerd Petermann wrote:
> > > 
> > > > Hi Thorsten,
> > > > 
> > > > my thinking was that inc/address does not set any 
> > > > tags which are not prefixed with mkgmap:
> > > > I see that your inc/address is a bit different to that in the default style,
> > > > but the only significant difference that I found is this rule:
> > > > mkgmap:country=DEU | mkgmap:country=AUT | mkgmap:country=CHE {set style:lang=german}
> > > > 
> > > > So, I see no problem as your inc/address also doesn't set name or place_name.
> > > > 
> > > > What do I miss?
> > > 
> > > This were only examples, the result is used by me to set mkgmap:street
> > > in some cases to prevent inc/address from setting it (workaround for some
> > > bad tagging, where people add addr:street to a highway, e.g.).
> > > 
> > > So in this special case I could add:
> > > highway=* & name=* & addr:street=* {delete addr:street} 
> > > to address, but I'm afraid that we loose a lot of flexible to
> > > "fix" wrong data by rules. And I'm not sure if adding the workarounds
> > > from points/lines/polygons to address is really always a good thing
> > > or can work.
> > > 
> > >   Thorsten
> > > 
> > > -- 
> > > Thorsten Kukuk, Senior Architect SLES & Common Code Base
> > > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
> > > GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
> > > _______________________________________________
> > > 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
> 
> 
> -- 
> Thorsten Kukuk, Senior Architect SLES & Common Code Base
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
> _______________________________________________
> 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/20150416/7ab8fe5c/attachment-0001.html>


More information about the mkgmap-dev mailing list