[mkgmap-dev] is_in filter

Mon Feb 6 20:45:15 GMT 2017

Hi Felix,

this is probably a completely different problem. A highway=* way might be inside or outside some admin_level=*
boundary, but it may also cross one or more boundaries and it might be part of the boundary.
I think the bounds file contains all information needed to split the ways when needed.

The current code in mkgmap checks only one (or a few) points of each way to set the mkgmap:admin_level values.

Can you give an example how the style rule would look like for your use case?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver at gmail.com>
Gesendet: Montag, 6. Februar 2017 21:22:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

I think it would be best to have this calculated the same as the bounds and the sea. I guess in principle most map creators are interested in two facts:
really urban (huge cities), urban (small cities/suburbs - say max 500 inhabitants) and rural/countryside.
The biggest use case is highway=residential (is it on the countryside - or in a built up area tiny city/suburb or city center)
also highway=tertiary, sometimes secondary is actually good for cycling in really rural areas - in big cities much less (actually best to avoid big cities alltogehter except on good quality cycleroutes)
highway=cycleway = often avoid in cities, but great on the countryside.

I imagine if this is precalculated - then the processing while creating the map will be very quick, just like addresses for housenumbers - or am I wrong?
Also this would allow more complex arguments for determining what is rural, what is urban - and what is a huge city... 3-4 categories from urban to rural should be enough for 99% of cases.

On 6 February 2017 at 20:55, Gerd Petermann <GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen at hotmail.com>> wrote:
Hi Carlos,

okay, I thought about this for a while. We need quite a lot of new code for this, so I think
the user interface should be as flexible as possible.
If we want to support a style function like is_in(<exp>)
where <exp> can be something like
landuse=residential
or more complex stuff like
landuse=forest | natural=wood
In short, I think it should support more or less all Tag_tests including regular expressions
and combined expressions. A complete style rule could look like this:
building=* & !is_in(landuse=residential | landuse=retail)   [0x13 resolution 24]
Those Tag_tests are used to filter the enclosing areas (closed ways, multipolygon-relations).

I have no idea how to code the part that parses the style file.
Is someone volunteering to code these changes?
I think about a new class IsInFunction in package uk.me.parabola.mkgmap.osmstyle.function
which would call an eval(element) method for each enclosing element. The eval method
should return true / false.

I'd like to code the needed methods to find the enclosing elements in an efficient way.

If nobody finds a way to code the above style changes
I can code a style function with a much simpler syntax like this:
is_in_<key><val>()
e.g.
is_in_landuse_residential()
or
is_in_natural_wood()
The name of the function gives the test:
The enclosing element must have a key <key> with the value <val>

Complex tests like regular expressions would not work with this.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila <cdavilam at orangecorreo.es<mailto:cdavilam at orangecorreo.es>>
Gesendet: Samstag, 4. Februar 2017 16:37:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

Yes, I think that would work.
I forgot to mention another use case. highway>residential which lies
inside residential areas. They have typically maxspeed lower than
outside residential areas, but are not correctly tagged in many cases.
Proposed filter could be used to lower maxspeed for those ways.

El 04/02/17 a las 16:18, Gerd Petermann escribió:
> Hi Carlos,
>
> I see a performance problem if mkgmap has to evaluate that for each element.
> I think it would be better to have a special tag like mkgmap:remove-if-in=<type>
> which would tell mkgmap to find out if the object lies (completely) within a polygon
> that has the given type. This can happen after processing all polygon elements.
> The polygons with the given type(s) could be placed in a spatial index if performance impact
> is too heavy.
> Do you think that would work as well?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila <cdavilam at orangecorreo.es<mailto:cdavilam at orangecorreo.es>>
> Gesendet: Samstag, 4. Februar 2017 16:06:20
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] is_in filter
>
> One matter that has been discussed several times on this list is the
> need to remove buildings. While removing buildings is becoming
> absolutely necessary in many cities, due to massive building imports, it
> may be quite convenient to keep them at rural or low densely populated
> areas. Would it be possible to have a filter to know if a building is
> inside/outside an area tagged landuse=residential, so that a different
> rendering may be applied. Ideally area size could be also evaluated.
> Perhaps some logic currently existing in mkgmap, used to assign
> addresses from bounds, could be reused.

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

--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich