Place names

Ben · 2009-01-27T18:48:52.000Z

Route planners use the place= tagged node to start the route from it would seem, but also renderers use this to display a name in relation to it’s position.

Is this an issue?

i.e. If the ‘place node’ is just a node on a road (in the centre of the town/village/city/etc), could the rendering program somehow shifts the name to a ‘reasonable’ location based on stated criteria, such as lack of data? or is this a mammoth task?

or…is it going to be necessary to have 2 separately tagged nodes. One for route starts, and one for the name display point?

Currently people seem to be both of these method. Personally I place the ‘place node’ off the road so that the name renders in a position that works well, but as a result the route planners start each route with a brisk walk to the road.

emj · 2009-01-27T23:49:58.000Z

This is an issue, because there is a no easy fix. Using two nodes is the easiest way, but:

They always say you should map what is there not for how it should look. There was a question about using place= tags on areas recently, this would probably be perfect for what you want to tell the renderer. Problem is place= on areas is not supported in mapnik, so what will happen is that osm2pgsql will place a fake node where it things the name should be (without any intelligence).

Lambertus · 2009-01-28T08:22:37.000Z

The Gosmore routing engine starts at the nearest suitable road node, so if you put the place name on or near a pedestrian road and you are planning a route by car then the routing algo will choose the nearest road where cars are allowed.

So it is not necessary to put a place name on a road (not from routing nor rendering viewpoint).

Ben · 2009-01-28T14:16:10.000Z

It is true that you should map what is there, not how it looks, (although this has to be one of the most broken rules since people ‘map what renders’) but place= is one element that this rule can’t be applied to when tagging a node, since the place is an area, so tagging within that area is ‘tagging what’s there’ so shifting it around doesn’t break this rule, and allows for a nicer rendering. Apart from this though I strongly stick to the ‘map how it is’ concept.

I think there are really 4 bits of data that can be stated. (Spelling it out to be sure…)

The administrative area of a village/town.
The village/town boundary (where the houses stop). For villages in particular the difference between 1 and 2 is huge, as the village will take up a tiny percentage of the admistrative area (in the UK this is so anyway)
The point at which people should leave from and be taken to when asking for a route from x to y.
The place at which the name is displayed. (Unless as I said above it’s possible for the renderer to make these artistic decisions.
Uses the relation type:boundary; boundary:administrative; admin_level=x; name=x
An area tagged with place=x and place_name=x? (also you (emj) stated area=yes? the conversation you linked to, which I’m not clear as to why if your tagging a closed way? (elaborate please!))
3 and 4 are the two I’m not clear on how to break apart.

If a route planner does ‘find’ nearest road to that node, (as in Gosmore example [which I havn’t used]) then that is defiantly better than starting with the ‘brisk walk’ but ideally the start point can be pre-stated in osm’s data to ensure that it is in the best possible spot, rather than nearest spot to the named spot.

So I think that yes, map how it is, when you can only do 1 choice, but if we can add 2, I see no reason why not also to have map-rendering data there, especially in this case where a singular point marked as ‘place=’ doesn’t exist in reality anyway usually, or a point/sign saying ‘start routes here’!. If there were giant signs to map then mapping how it is would address this issue.

A picture speaks a thousand words, so this should make it simpler. It also makes me wonder. If 2. is 2 different areas, should we keep them as 1 by linking the apparent 2 seperate areas into 1 by sticking ways both ways along the road between them? Seems messy.

Lambertus · 2009-01-28T15:29:05.000Z

So, if you’re blindingly following your satnav then you will end up somewhere in the outskirts of that town if you set your satnav to ‘Atterton’. Wouldn’t it be better to put the place node on an important junction (around which many places evolved ages ago) or a central square?

Also, in the Netherlands we have many boundaries as a result of the AND import. One of which is the place boundary (built-up area) which also has a place tag afaik. Both the node in the center as the area are crucial (imho) to determine which roads belong to which place as well as driving straight up to it’s center.

I think that “placing the place name based on how it’s rendered” should be taken completely out of the discussion: this behavior can differ between each renderer or stylesheet. There will never be a real standard.

Ben · 2009-01-28T20:35:28.000Z

I’m sure it’s been misunderstood, because that’s what I said. My point exactly was that if the place node isn’t on the centre point then it will take you to the outskirts of a town, so yes it would be better to put the place node on an important junction. But…this is assuming the place=node is there ‘souly’ for route planning.

I’m fine not sticking the place node with any relation to how it renders, If I can be assured that it’s possible to position the name well from the renderers perspective rather than the nodes position. I’m doughtful of this though. From a programming perspective maybe just plonking in the middle is fine, but when trying to make a map excel graphically, this isn’t really adequate. Take a look at OS’s 1:50k maps in the UK. The names are not plonked on the middle point; there put in a place that minimally effects not being able to see other data. Even over big cities they are shifted so that their not directly on top of other text, stations, junctions etc, but just over generic housing. Likewise for phone boxes, which I imagine have 2 points. 1 where it is, and 1 where the symbol goes. These are then linked with a line.

Just to note: Sticking place on a node not directly connected to the road, or the main road meeting point of a place is hardly rare. I would say the opposite for everywhere I’ve mapped. In contrast, I’ve rarely seen nodes on the way, although I do see it.

Not sure what the multiple boundaries from AND is in relation to. Should there be multiple? or is this data that requires cleaning? This doesn’t contradict what I said as far as I can see though. In my breakdown of how I’m currently understanding it, nothing in there stopped the “node in the centre and the area” being added which “are crucial”. (points 2 and 3) Maybe some misunderstanding going on here.

emj · 2009-01-29T00:02:14.000Z

Ben:

But…this is assuming the place=node is there ‘souly’ for route planning.

You place the node either
1. where the place really is, based on cultural, geographical or administrative info
2. where the name will render most beautifully
3. where you will get the best match for navigation software.

For me it’s 1. all the way, it creates problems yes, but it’s really the only way that you can be sure that it will render in the future. Let the software take care of the placement of text.

I agree with you though, your motto “Everyone maps the things that renders” is better than “don’t map for renderers”. I’ve always thought that you try to make a map to describe what is there, and the renderers are a vital part of that. So I understand why you would change the data to fit what is good on the map… So I think “don’t map for renderers” is an over simplification, my strong hatred against it is more of a irritation that I think it’s just to naive.

Ben · 2009-01-29T01:19:35.000Z

hmm, your right, there’s 3 variations rather than 2 I suppose. The 1st is where a search result would take you to on the map I guess, the 2nd for the image you see, and 3rd for route planning software.

For me it’s ‘which ever is correct’. Currently I use 2. Assuming there is only ever 1 node tagged, then only 1 can be correct and I’ll switch to that, but ideally I think we need to allow all, rather than having different people choose 1, 2 or 3, becuase I dought consistency that way.

For the place= that ‘looks prettiest’, could it be a node tagged the same way as 1 on the road. But like barrier=gate observes that it’s on a way when getting rendered, the place=xyz could observe it’s on a way and not render, but instead be used for route planning, and vice versa. This doesn’t address the issue of having the place centre and place navigation start point being different though. These would surly need additional keys.

There was definite cynicism in that motto by the way! I find it incredibly frustrating that people map incorrectly for it to appear, and especially that consequently renderers overpower any vote or discussion on any wiki page and forum or mailing list conversation.

Are you saying you have ‘strong hatred’ for that quote, or you agree with the quote and have strong hatred for what it refers to?

When you say ‘let the software take care of’ it. Is it plausible that this actually will happen? It does seem like a lot of work, if possible at all. I say that just based on my inibilty to say where the names are except by saying ‘a place that looks nice’. It seems rather independent of rules. It does seem like a mammoth task also, and from what I have observed in the history of OSM, the people with the skills to do this tend not to commonly find arguable-pedantic things like place=name placement remotely interesting and/or a necessary thing to do.

emj · 2009-01-29T14:02:06.000Z

Ben:

but ideally I think we need to allow all, rather than having different people choose 1, 2 or 3, becuase I dought consistency that way.

Astute observation: placement=routing, placement=geographically, placement=rendering, perhaps as a relation?

I’m highly dubious anyone will use it, though having it available might be a good idea. Look at source= for something similar.

Ben:

Are you saying you have ‘strong hatred’ for that quote

I updated my post to remove the strong wording…

Ben:

When you say ‘let the software take care of’ it. Is it plausible that this actually will happen?

Yes. How long? I don’t know. As Lamberstus states, What ever way you choose to solve this in you will need support from all software that renderers Openstreetmap.

Though maybe mapnik+osm2pgsql is enough, then you just need to propose a way that this can be done in (see first). But as you say the maintainers of mapnik+osm2pgsql rules are not always happy to implement and maintain ideas that seems very easy on paper (wiki).

Ben · 2009-01-30T01:14:49.000Z

Ok, thanks for the suggestion. I might proposed that at some point then.

If people don’t use it then maybe 1 of those 3 will be recognised as standard, when only place= exists.

TEL0000 · 2009-02-05T10:27:17.000Z

1 and 3 are in fact the same place, because the user expects navigate from where the place really is, based on cultural, geographical or administrative info.

2 is simply impossible to map, because you’ll never know which renderer the user will use…

Ben · 2009-02-11T00:03:54.000Z

I’d say 1 and 3 are close, but not the same. A good starting point would usually be the main junction, where as the actual middle where the search result should link to may be off to one side of this. In the case of UK villages I can think of a few examples, and for UK towns, which build up next to large areas of land belonging to a manor, the town would expand off in the other direction.

2 isn’t impossible, I do it currently, and it works. The difference would probably just be centre align or left align. This is yet to be an issue.