OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2019-01-07 05:20:41

Hornissen
Member
From: Germany
Registered: 2019-01-06
Posts: 5

tooltip for residential area

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 = <city>" 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.

Offline

#2 2019-01-07 10:14:45

GerdP
Member
Registered: 2015-12-18
Posts: 843

Re: tooltip for residential area

I'd also like to have that and I think there should be no need to change OSM data.
@ligfietser: I think you just have to add something like

landuse=residential {add name='${mkgmap:city}'}

before rendering landuse=residential.

Offline

#3 2019-01-07 14:28:57

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

Thanks for the suggestion Gerd, I can try that, let' s see if that works!

Offline

#4 2019-01-07 15:46:51

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

ligfietser wrote:

Thanks for the suggestion Gerd, I can try that, let' s see if that works!

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.

Offline

#5 2019-01-07 17:39:22

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: 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.

Utrecht.jpg

Offline

#6 2019-01-07 17:57:55

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

Hornissen wrote:

Tagging the feature "landuse = residential area" with "name = <city>" 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.

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!

map.jpg

Last edited by ligfietser (2019-01-07 18:19:20)

Offline

#7 2019-01-07 18:43:24

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

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.
map2.jpg

Offline

#8 2019-01-07 21:06:03

Hornissen
Member
From: Germany
Registered: 2019-01-06
Posts: 5

Re: tooltip for residential area

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".

Offline

#9 2019-01-07 21:48:29

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

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.

Offline

#10 2019-01-08 14:14:00

GerdP
Member
Registered: 2015-12-18
Posts: 843

Re: tooltip for residential area

@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}' | ...}

Offline

#11 2019-01-08 17:17:30

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

Hi Gerd,
I know what you mean, but this is already taken care for in https://github.com/ligfietser/mkgmap-st … nc/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.

Offline

#12 2019-01-08 21:35:25

Hornissen
Member
From: Germany
Registered: 2019-01-06
Posts: 5

Re: tooltip for residential area

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.

Offline

#13 2019-01-09 09:46:40

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

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.

Offline

#14 2019-01-09 21:38:46

Hornissen
Member
From: Germany
Registered: 2019-01-06
Posts: 5

Re: tooltip for residential area

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

Offline

#15 2019-01-10 07:46:01

GerdP
Member
Registered: 2015-12-18
Posts: 843

Re: tooltip for residential area

ligfietser wrote:

Hi Gerd,
I know what you mean, but this is already taken care for in https://github.com/ligfietser/mkgmap-st … nc/address

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 <small> in <big> or <small>(<big>). 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.

Offline

#16 2019-01-10 09:58:16

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

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

Last edited by ligfietser (2019-01-10 10:28:16)

Offline

#17 2019-01-10 11:38:06

GerdP
Member
Registered: 2015-12-18
Posts: 843

Re: tooltip for residential area

The rules look OK to me.

Offline

#18 2019-01-10 11:42:54

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

Here one example how confusing and complicated it can get: https://www.openstreetmap.org/way/25903 … 4/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.

Last edited by ligfietser (2019-01-10 11:44:10)

Offline

#19 2019-01-10 12:14:53

GerdP
Member
Registered: 2015-12-18
Posts: 843

Re: tooltip for residential area

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)

Offline

#20 2019-01-10 12:36:41

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

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.

Offline

#21 2019-01-10 21:38:43

Hornissen
Member
From: Germany
Registered: 2019-01-06
Posts: 5

Re: tooltip for residential area

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.

Offline

#22 2019-01-10 21:56:20

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,087
Website

Re: tooltip for residential area

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.

Offline

#23 2019-01-28 22:20:36

DTeelde
Member
From: Eelde
Registered: 2010-05-30
Posts: 16

Re: tooltip for residential area

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. … 79/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. … 92/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".


Garmin GPSmap64s+Gazelle Ultimate

Offline

#24 2019-01-28 22:32:22

GerdP
Member
Registered: 2015-12-18
Posts: 843

Re: tooltip for residential area

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.

Offline

Board footer

Powered by FluxBB