is_in filter

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

is_in filter

Carlos Dávila-2
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Gerd Petermann
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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Carlos Dávila-2
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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Gerd Petermann
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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Felix Hartmann-2
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 <[hidden email]> 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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Gerd Petermann
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 <[hidden email]> im Auftrag von Felix Hartmann <[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> im Auftrag von Carlos Dávila <[hidden email]<mailto:[hidden email]>>
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 <[hidden email]<mailto:[hidden email]>> im Auftrag von Carlos Dávila <[hidden email]<mailto:[hidden email]>>
> 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
[hidden email]<mailto:[hidden email]>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]<mailto:[hidden email]>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Carlos Dávila-2
In reply to this post by Gerd Petermann
Hi
First option sounds better, but if nobody can code it by now (sorry, I'm
not dev1eloper) second option can be a good start point. Probably a
combination of rules of the second type could get a similar effect:
!is_in_landuse_residential() & !is_in_landuse_retail() [blablabla...]

El 06/02/17 a las 20:55, Gerd Petermann escribió:

> 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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
> 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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
>> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Gerd Petermann
Hi Carlos,

okay, I keep that in mind. I've already coded the simple solution for testing and
tried to re-use one of the existing spatial indexes for this
and found that none works. Another problem is that the existing multipolygon code
is always chopping polygons to cut out inner rings. So, I think the first step is to
rewrite the mp code (I already started that in the split-shape branch). I hope I can
make that part much faster.
2nd step is to find a good index, maybe Felix is right and this should better be done
in a separate step.
Anyway, I expect that this function can easily increase run time by > 100% .

Gerd

Carlos Dávila-2 wrote
Hi
First option sounds better, but if nobody can code it by now (sorry, I'm
not dev1eloper) second option can be a good start point. Probably a
combination of rules of the second type could get a similar effect:
!is_in_landuse_residential() & !is_in_landuse_retail() [blablabla...]

El 06/02/17 a las 20:55, Gerd Petermann escribió:
> 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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
> 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 <[hidden email]> im Auftrag von Carlos Dávila <[hidden email]>
>> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Felix Hartmann-2
In reply to this post by Gerd Petermann

On 6 February 2017 at 21:45, Gerd Petermann <[hidden email]> wrote:
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.

Well I hoped that it would be splitted therefore at boundaries if needed.

e.g. I would do:
highway=cycleway & mkgmap:urban=yes [road_speed=1 road_class=0]
highway=cycleway & mkgmap:rural=yes [road_speed=2 road_class=4]
highway=cycleway & mkgmap:very_urban [road_speed=0 road_class=0]


Optimum would be to find cycleways which run in urban areas alongside roads and heavily downclass them - but I guess that is even less doable.


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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Gerd Petermann
Hi Felix,

looks simple enough, but what would be the rule to set the new special tags like mkgmap:urban?
Do you think those could be calculated somehow using only the data used to compile the bounds file?
If yes, please give more details.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Felix Hartmann <[hidden email]>
Gesendet: Dienstag, 7. Februar 2017 21:32:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

On 6 February 2017 at 21:45, Gerd Petermann <[hidden email]<mailto:[hidden email]>> wrote:
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.

Well I hoped that it would be splitted therefore at boundaries if needed.

e.g. I would do:
highway=cycleway & mkgmap:urban=yes [road_speed=1 road_class=0]
highway=cycleway & mkgmap:rural=yes [road_speed=2 road_class=4]
highway=cycleway & mkgmap:very_urban [road_speed=0 road_class=0]


Optimum would be to find cycleways which run in urban areas alongside roads and heavily downclass them - but I guess that is even less doable.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

nwillink
In reply to this post by Carlos Dávila-2
For years now I have been keeping all buildings as a separate transparent gmapsup /img  giving it a higher priority/draworder then my normal maps - It has speeded up my daily runs without loss of detail - same could be done for rivers/streams etc.
As a bonus I can ,if I wanted to, switch off/on buildings on my device, bit like contours.
I update my buildings.img when necessary.

This is not an answer to the initial problem but it works

r

Nick
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Felix Hartmann-2
In reply to this post by Gerd Petermann

On 7 February 2017 at 21:54, Gerd Petermann <[hidden email]> wrote:

looks simple enough, but what would be the rule to set the new special tags like mkgmap:urban?
Do you think those could be calculated somehow using only the data used to compile the bounds file?
If yes, please give more details.

well that's the hard part - I know. It could be a mix of several things - best I could think of is densitiy of POI or density of addresses.

I'ld guess looking at density of POI and density of building=* - plus the bigger the size of the building the more it has to be assumed it's urban and some crosscheck with the bounds data would be enough. That should then end up in a static file just like sea data and bounds. It would also of course be possible to use that data to exclude buildings in cities - and more ideas.

Even just density of POI and density of building=* (look at how much space the building occupies - e.g. if inside a squared area more than 20% of space is taken up by buildings - it's highly urban. 5-20% is a bit mixed, <5% is rural.


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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Gerd Petermann
OK, got the idea. Not sure if that can be computed for planet in a reasonable time, but for a single tile it would not be too much.

I have to think about this for a while.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Felix Hartmann <[hidden email]>
Gesendet: Dienstag, 7. Februar 2017 22:20:04
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

On 7 February 2017 at 21:54, Gerd Petermann <[hidden email]<mailto:[hidden email]>> wrote:

looks simple enough, but what would be the rule to set the new special tags like mkgmap:urban?
Do you think those could be calculated somehow using only the data used to compile the bounds file?
If yes, please give more details.

well that's the hard part - I know. It could be a mix of several things - best I could think of is densitiy of POI or density of addresses.

I'ld guess looking at density of POI and density of building=* - plus the bigger the size of the building the more it has to be assumed it's urban and some crosscheck with the bounds data would be enough. That should then end up in a static file just like sea data and bounds. It would also of course be possible to use that data to exclude buildings in cities - and more ideas.

Even just density of POI and density of building=* (look at how much space the building occupies - e.g. if inside a squared area more than 20% of space is taken up by buildings - it's highly urban. 5-20% is a bit mixed, <5% is rural.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Felix Hartmann-2
well - that's why I think it should be precompiled. Do it once - no matter if planet takes 48 hours on a potent machine - then redo it like every two years... I do believe it will slow down mkgmap too much if compiled at the same time as the maps themselves.

On 7 February 2017 at 22:41, Gerd Petermann <[hidden email]> wrote:
OK, got the idea. Not sure if that can be computed for planet in a reasonable time, but for a single tile it would not be too much.

I have to think about this for a while.

Gerd
________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Felix Hartmann <[hidden email]>
Gesendet: Dienstag, 7. Februar 2017 22:20:04
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in filter

On 7 February 2017 at 21:54, Gerd Petermann <[hidden email]<mailto:[hidden email]>> wrote:

looks simple enough, but what would be the rule to set the new special tags like mkgmap:urban?
Do you think those could be calculated somehow using only the data used to compile the bounds file?
If yes, please give more details.

well that's the hard part - I know. It could be a mix of several things - best I could think of is densitiy of POI or density of addresses.

I'ld guess looking at density of POI and density of building=* - plus the bigger the size of the building the more it has to be assumed it's urban and some crosscheck with the bounds data would be enough. That should then end up in a static file just like sea data and bounds. It would also of course be possible to use that data to exclude buildings in cities - and more ideas.

Even just density of POI and density of building=* (look at how much space the building occupies - e.g. if inside a squared area more than 20% of space is taken up by buildings - it's highly urban. 5-20% is a bit mixed, <5% is rural.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Merging layers in a map (was is_in filter)

Carlos Dávila-2
In reply to this post by nwillink
El 07/02/17 a las 22:06, nwillink escribió:

> For years now I have been keeping all buildings as a separate transparent
> gmapsup /img  giving it a higher priority/draworder then my normal maps - It
> has speeded up my daily runs without loss of detail - same could be done for
> rivers/streams etc.
> As a bonus I can ,if I wanted to, switch off/on buildings on my device, bit
> like contours.
> I update my buildings.img when necessary.
>
> This is not an answer to the initial problem but it works
>
> r
>
> Nick
Thanks Nick for the hint.
I had already tried this approach to separate my topo map into three
layers: base map, topo specific elements and contour lines but I get
very different behavior on different Garmin models. Up to now I have
done only a simple test with the commands and results shown below:
#Base map:
java -Xmx600m -ea -jar mkgmap.jar --bounds=bounds.zip --route --latin1
--code-page=1252 --country-name=ESPAÑA --country-abbr=ESP
--family-name="OpenStreetMap Extremadura" --family-id=113 --product-id=1
--description="OpenStreetMap-Extremadura"
--series-name="OSM-Extremadura"  --area-name=España
--overview-mapname=ESP-113 --mapname=55113001 --index
--process-destination --process-exits --housenumbers --add-pois-to-areas
--adjust-turn-headings --report-similar-arcs --link-pois-to-ways
--location-autofill=is_in --drive-on=right
--style-file=../resources/styles --style=base typ/ESP-113.TYP
extremadura.o5m

#Topo layer
java -Xmx600m -ea -jar mkgmap.jar --family-id=513 --product-id=1
--family-name="Topo Extremadura" --series-name="Topo-Extremadura"
--area-name=España --overview-mapname=ESP-513
--overview-mapnumber=55513000 --transparent --draw-priority=26 --latin1
--code-page=1252 --style-file=../resources/styles --style=topo
extremadura.o5m

#Merge all layers (contours are prebuilt transparent 60213*.img files
with draw-priority=28)
java  -ea -jar mkgmap.jar --latin1 --code-page=1252
--description="OSM+Topo-Extremadura" --country-name=ESPAÑA
--country-abbr=ESP --family-name="OSM+Topo Extremadura" --family-id=313
--product-id=1 --series-name="OSM+Topo Extremadura" --area-name="España"
--overview-mapname=ESP-313 --overview-mapnumber=65313000 --index
--show-profiles=1 ../mapas/extremadura/55113*.img
../mapas/extremadura/6324*.img ../mapas/extremadura/60213*.img
../mapas/extremadura/ESP-313.TYP

Legend HCx: each single tile must be enabled/disabled separately. Tiles
of each layer are identified as OpenStreetMap-Extremadura (base map),
OpenStreetMap (topo) and Curvas de nivel (contour lines).
etrex 20x: only two maps are shown in map info: OpenStreetMap (base map)
and OSM+Topo Extremadura (all layers). If only base map is enabled,
background is black.
Edge 800: map info shows three maps, but they all have the same name and
properties and it's necessary to enable/disable them by turns to know
which is which.
As I've said, it was only one test and I probably have to play with
description parameters to get a more homogeneous behavior, so any hint
would be much appreciated.
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

popej
In reply to this post by Gerd Petermann
Hi,

I like your ideas about is_in and urban areas. But I have doubts about
practical results. IMO areas like landuse=residential or place=city/town
aren't mapped well in OSM data. So even if you add some new features to
mkgmap, it won't be useful, because input data is not precise.

Some consideration about urban area. I think using buildings or house
numbers as indication of urban area won't be reliable. Mostly because
these are data from imports, so some cities get them while others still
do without. Probably highway's junctions (crossroads) could be the best
indication of urban area. Roads are usually mapped correctly and number
of junctions shows complexity of road network.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

nwillink
r Carlos

In my case with Oregons and GPS64  I also rename the gmapsupp.img to defined the main label.
Reply | Threaded
Open this post in threaded view
|

Re: is_in filter

Felix Hartmann-2
In reply to this post by popej

On 7 February 2017 at 23:52, Andrzej Popowski <[hidden email]> wrote:
I like your ideas about is_in and urban areas. But I have doubts about practical results. IMO areas like landuse=residential or place=city/town aren't mapped well in OSM data. So even if you add some new features to mkgmap, it won't be useful, because input data is not precise.

Some consideration about urban area. I think using buildings or house numbers as indication of urban area won't be reliable. Mostly because these are data from imports, so some cities get them while others still do without. Probably highway's junctions (crossroads) could be the best indication of urban area. Roads are usually mapped correctly and number of junctions shows complexity of road network.

You have a good point there - I also think residential and city/town are not that well mapped. Housenumbers are pretty well mapped in many european countries though - but not in the rest of the world. Buildings I would guess are sufficiently mapped in most european countries in OSM.
Road junctions have one problem - actually residential areas (as in where people are living) have most junctions, while city centers / commercial areas feature much bigger buildings and less intersections.  Maybe the kind of roads in such areas would help to better identify them. Urban areas would be easy to find however - take the amount of crossings from highway=track/path/cycleway vs highway=residential/primary-secondary-tertiary-unclassified and the picture should be very clear.

I think both methods will allow for an improvement in routing as well as an improvement to exclude clutter from buildings in maps if we can derive a classification level of urbanisation from it and feed it to mkgmap like bounds and sea files.
My idea would be there should be an analysis of 400x400m patches - then join them and find out how big the area becomes - any areas that have more than 3-4 connected patches can then be classified as urban in the "urban_bounds" file - if it's one or two of such patches - I'ld rather keep the buildings in my maps and also still consider it rural (because for a tiny mountain village - I'ld like to keep them - however for a mountain town like Zermatt, Ischgl or their like - I'ld prefer to remove them - while for big cities is essential to remove the buildings.


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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev