If I move the cursor over a map feature in my Garmin device (eTrex Vista HCx) additional information will pop up - like the name of the street. The same happens when moving the mouse in programs like MapSource. If no information is available, the kind of feature will be just displayed (like “residential area”). I think it would be useful if the name of the city was shown in case of residential area. My question: how is the feature to be tagged in OpenStreetMap in that OSM maps for Gamin will show the right tooltip?
Tagging the feature “landuse = residential area” with “name = ” would result in my favourite tooltip. But the tag “name” has been depreciated by the OSM community. They propose the tag “is_in” or the like.
Unfortunately, OpenFietsMap does not follow this tag.
Well, after thinking about this, I dont think this is such a good idea. All nameless polygons will get a name of the city and it will be rendered on the map. If a city consists of hundreds of small residential areas there will be city names all over the place. Often there are towns within a city, for instance town X with admin_level=8 within city Y in admin_level=6. Their adresses belong to a town X, not city Y. If mkgmap makes it city Y than my map users that live in X will complain their town name is wrong. So I have to look in which highest level this area is located. And if there are no admin districts, where does mkgmap gets the city from? The nearest city place node? That is not always true. I dont like mkgmap guessing info that is not entered in osm at all.
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.
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.
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.
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.
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
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.
