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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@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@hotmail.com<mailto:GPetermann_muenchen@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es<mailto:cdavilam@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es<mailto:cdavilam@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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

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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> 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 <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> 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

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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> 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 <GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@hotmail.com>> 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

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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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.

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

On 7 February 2017 at 23:52, Andrzej Popowski <popej@poczta.onet.pl> 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

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.