tooltip for residential area

I’ve done some tests. Because I don’t render the landuse=residential names (labels are invisible) it does not look as bad as I thought. Besides that, the problem with a hierarchy of a town within a city is already taken care of in the “address” file. So I can add mkgmap=city when the name is empty or use is_in as substitute for the name tag when is_in is given and name the name tag not entered.

Can you give a good example of is_in?

If I look at this area https://www.openstreetmap.org/way/28988522 I dont think it is a good alternative tag for the name.
It will render as Daun,Trier,Rheinland-Pfalz,Bundesrepublik Deutschland,Europe instead of “Stadtkyll” what I expect.

Edit1:
If I render it now with the improved style, it shows in the tooltip “Kyll” instead of residential area.
Apparently mkgmap assigns addresses in Stadtkyll to the placename “Kyll”, is that correct? If not, something is either wrong with the administrative boundaries or my styles.

Edit2:
Found your issue with “Mögglingen”. With my improved style it now shows up in the tooltip as Mögglingen. So is_in:village tag is unneccesary, the administrative district relations are already in OSM and mkgmap can use this. So this issue can be solved by adapting the OFM style. Thanks!

And here is a minor issue what I already mentioned. At Hermannsfeld, the tooltip shows Essingen.
This is because the village is in the district of Essingen. Maybe Gerd can find a workaround for this? I think it is good enough, it definitely looks better than before.

Thanx, Ligfietser, for trying Gerd’s proposal. Nothing is perfect, but your results are more useful than just displaying “residential area” anyway, I think so. As the labels are hidden, the map is not overcrowded (your post #5). If someone was not satisfied with the default tooltip “Essingen”, he could tag “is_in:hamlet = Hermannsfeld”.

I am not familiar with the hierarchy of towns. There might be better solutions. The best tooltip would be “Essingen-Hermannsfeld” due to the city-limit sign “Hermannsfeld \newline Gemeinde Essingen”. I assume, this kind of tooltip would require lots of workarounds in order to avoid doubling like “Mögglingen-Mögglingen”.

Well, I still dont use is_in:something (continent, country, state, province, city, town, suburb, quarter village, hamlet, locality) because someone can use several of these tags and what should I do then? Right now I’m happy with the administrative boundaries. Anyway, the tooltip Essingen is usefull because it shows to which Gemeinde Hermannsfeld belongs.

@ligfietser: Maybe you can change the rule to find the highest mkgmap:admin_level* that is set? Something like


landuse=residential & name!=* {add name='${mkgmap:admin_level11}' |'${mkgmap:admin_level10}' | '${mkgmap:admin_level9}' | ...}

Hi Gerd,
I know what you mean, but this is already taken care for in https://github.com/ligfietser/mkgmap-style-sheets/blob/master/styles/Openfietsmap%20full/inc/address
In the case of Hermannsfeld, it doesn’t help anyway because there is no admin level for this hamlet. I think I’ll leave it like it is now.

From practical point of view, I would prefer the lower admin level. I would like to quickly find my location on a paper map. When cycling I usually do not pass the town signs which are only located at the large car roads. My GPS device only shows a very small section (typical zoom level 120 ~ 300 m). I would see the label “Hermannsfeld” for a small hamlet without scrolling, but not for a larger suburb. In the latter case, I want the tooltip to show me the whatsoever “right” name when moving the cursor over residential area.

@ Ligfietser: What will the tooltip now show for Unterkochen (N48.81687° E10.12534°) - city “Aalen” or suburb “Unterkochen”? I am repeating: “Aalen-Unterkochen” would best match all needs. I understand your objection for simple solution since the OSM data are not uniformly provided. So I am returning to my initial question: How shall I tag the residential area? With “name = Aalen-Unterkochen” or are we inventing a new tag “tooltip” which both override your default?

I assume, the task will become more complicated for huge cities like Berlin with really large suburbs like Steglitz (> 300000 habitants). But we shall get smaller towns right first.

For Unterkochen it shows Aalen, because all addresses in this suburb are also Aalen. If you tag the residential with name = Aalen-Unterkochen, it will show up as Aalen-Unterkochen. That’s prefectly fine with me but some people might not agree with this, they see it as tagging for the renderer. What they actually dont like is the rendering on the standard osm map, double rendering of the residential area name and the place node name. You can also see removing the name tag from this polygon as tagging for (another) renderer. Also inventing another tag to show up as tooltip on the Garmin maps is tagging for the renderer. It has caused some edit wars already…

At the moment, I think the best tooltip is showing in what place the nearby addresses belong to and that’s what it is showing right now (well, in the next updates of the OFM). I agree it is not ideal but it is better than it was.

Okay. I am awaiting for the February update of OpenFietsMap. Thanks for your work

Not really. The code tries to find a reasonable value for mkgmap:city , here we always want to find the “smallest” named boundary, don’t we?
Anyway, showing the next city is much better than nothing, and it will get quite complicated to show both because the order would be important. One probably cannot simply use a pattern like in or (). In Germany we write e.g. Berlin Mitte or Bremen Huchting and not “Mitte in Berlin” or “Mitte(Berlin)” or “Huchting in Bremen”. I guess there are lots of country specific rules for that.
Maybe something we should discuss in the mkgmap forum.

I see what you mean, by looking at the German situation.
And how about is_in:… tag, how to know what must be the lowest order? Does this sound ok:

landuse=residential {add name='${is_in:hamlet}' | '${is_in:locality}' | '${is_in:neigbourhood}' | '${is_in:quarter}' | '${is_in:village}' | '${is_in:town}' | '${is_in:suburb}' | '${is_in:city}'}
landuse=residential {add name='${mkgmap:admin_level11}' | '${mkgmap:admin_level10}' | '${mkgmap:admin_level9}' | '${mkgmap:admin_level8}' | '${mkgmap:admin_level7}' | '${mkgmap:admin_level6}'}

Not sure if is_in:city must be put before admin_level11, 10 or 9 or after all admin_level rules?
And I dont want to spend time to find out about tagging a district within a city or within a metropole, thats too complicated and too different in each country.

Edit:
-This rule looks much better for instance in Berlin, where all addresses have the city name Berlin, but now it shows at least the districts in the tooltip like Kreuzberg, Mitte, Prenzlauerberg etc
-Forgot to mention there are also quarters, localities, neighbourhoods etc

The rules look OK to me.

Here one example how confusing and complicated it can get: https://www.openstreetmap.org/way/259031259#map=17/48.88074/10.05814
Himmlingsweiler, a hamlet or district of the town of Fachsenfeld. Is mapped as node as suburb, which should be a neigbourhood or maybe quarter (of Fachsenfeld). The residential area is tagged with is_in:village=Fachsenfeld. In my style rules it will get Fachsenfeld as tooltip but you actually want to see Himmlingsweiler. Best way is to give it name=Himmlingsweiler. There is nowhere stated in the wiki that a name tag is forbidden on the residential area tag! Now you will get this inconsistent mapping. Fachsenfeld is mapped as suburb too. Imho this should be tagged as town or village. That it is part of the municipality of Aalen is already mapped by the admin_districts.

I am not sure why name on landuse=residential isn’t wanted. I think the problem is that even the use of l=r is not clear. Some mappers create one large (multi)polygon for a city, others split them at each road. For the latter, you might see the same name=xyz on many (if not all) small areas and that would be wrong because a single part of the city should not be named like the city (this is what the changeset discussion points out)

Yep, this is an ongoing discussion at the Dutch community as well. Main problem is that the name is rendered twice, so it is more like a rendering problem of OSM Carto style.

I do not specialize in adminstration levels nor their mapping in OSM. The website of Aalen explains: The city is divided in suburbs (Stadtbezirke or Ortschaften, respectively) like Unterkochen or Fachsenfeld. They were independent villages in history until the territorial reorganization in the 1970s. Their subdivisions (Teilorte) are assigned to them, for instance, Himmlingsweiler belongs to Fachsenfeld. The lowest admin level (Himmlingsweiler) are printed on the paper city map (scale 1:20000) as well as on the paper cycle map (1:75000), although you will not see any city limit sign for Himmlingsweiler in nature, because the residential area is merged with Fachsenfeld. But Waiblingen is well separated and is announced with its own town sign (Waiblingen \newline Stadt Aalen).

I agree with Ligfietser that it is impossible to define the perfect tooltip automatically. In this case, the mapper shall add an appropriate tag.

Thanks for the explanation Hornissen. I added the is_in:… tag before the admin levels so at least you can try now if the tag is_in:hamlet for Hermannsfeld and Himmlingsweiler is working for your case.

I have used OpenFietsMap Benelux with this new feature. First of all: thanx for this option. Much better than “residential area” or “bebouwde kom” in Dutch.

At Eelde, my living place, happens something strange. Eelderwolde is shown as ToolTip.
OFM_Eelde
Strang. The place Eelderwolde is about 5 km north of Eelde.

This is caused by a very small overlap of the residential area with Eelderwolde at this point https://www.openstreetmap.org/?mlat=53.16579&mlon=6.55602#map=18/53.16579/6.55602.
A combination of the (greater) parts of admin_levels should be very nice: Eelde-Paterswolde is also display on the traffic signs for the city limit.
When using all parts of the lowest admin_level, it would result in “Eelderwolde-Paterswolde-Haren-Eelde” because there is also a small overlap with Haren (province Groningen). https://www.openstreetmap.org/?mlat=53.15792&mlon=6.56390#map=18/53.15792/6.56390
This happens also at many more places with a common border.

For this residential area I will change it later into “is_in=Eelde-Paterswolde”.

I think the problem here might be the way how mkgmap calculates the values for a way.
For a way with n nodes it will look at node n/2 and use the values of this position. For closed ways it could be better to calculate the centroid or something like that.