Hi. We meet often wrong positioned names. For example, look at all those "island"-s rendered right over water/blue area objects in this link:
http://www.openstreetmap.org/#map=13/38.0146/-121.5068
How to correct them?

asked 03 Jan '14, 20:32

sanser's gravatar image

sanser
665353653
accept rate: 5%


Well OSM has a basic rule that is called 'don't tag for renderers', so you need to pay attention, that you don't try to tweak just to make it look good at the osm.org default rendering. This might break the semantic of the internal geodata or break other renderings or processing.

So if ther label position is determind by finding the mean coordinates of the shape (here: island outer ways), there you can't do anything, as it's calculated by the Mapnik2 renderer. I know that there was a ticket at the old TRAC, but if you like, you can search and maybe open a new issue for the style, that might be pushed upstream to the Mapnik devs.
If the label appears using a place=* node, you can just move them till it fit's the reality.

permanent link

answered 03 Jan '14, 21:49

iii's gravatar image

iii
4.9k63880
accept rate: 11%

Not quite pleased with the answer(s) for the following reasons: 1. The SkippyMap is the OSM's REFERENCE map and it is probably the most visited WEB map of the Planet today; 2. The question implicitly points to a serious systematic error somewhere on the way from the source data until the client rendering; 3. There should be a limit how far the "we are not tagging for renderers" saying should be used as an excuse for serious errors; and 4. The misplaced name examples in the permalink are there in years indicating weaknesses in the public Inspectors used in the data preparation.

(06 Jan '14, 08:55) sanser
2

I'm not here to argue, I can just point you to the reasons that I know.

to 1.) There is no 'reference' map as OSM are just data per project definition. An incomplete overview is http://wiki.openstreetmap.org/wiki/Maps
to 2.) ? This is Open Source and the bug is/can be reported and be fixed. Currently nobody seems to have the time to do so or an idea for a serious solution without breaking other behaviour/performance.

(06 Jan '14, 09:06) iii
3

to 3.) It's not an excuse, it's a basic principle to avoid that the community permantly alters the data just because the semantic fit's for ones processing usecase better thant for the others.
to 4.) We don't have inspectors or a professional QA. The very basic QA that the (local) community does is basically to monitor the data and guide new users in useful tagging etc.

P.S: I don't like this style of allegations in a public support board. You are welcome to help on working on that topic.

(06 Jan '14, 09:09) iii
5

iii has given you an accurate answer, sanser. If you are "not quite pleased with it" you are welcome to help fix the underlying issue, but shooting the messenger isn't going to get you anywhere and will make people less likely to help you in future.

(06 Jan '14, 10:09) Richard ♦

Whilst not being a native of that part of the world, I've flown over it a few times. The GNIS imported data (which is the basis for the names there I think) has called some things "islands" and some things "rivers", but from the air it just looks like one large wetland with some "slightly less damp" and some "slightly more damp" areas.

These "islands" and "rivers" don't always have well-defined boundaries - unfortunately you can't always expect what's there to match your pre-conceived notion of what a feature should look like. Whoever's mapped that area has used GNIS, NHD and (by the looks of it) Bing, and they've done a good job reflecting those sources.

With regard to the rendering, I can't actually see an example where a label is grossly misplaced, only one where the name being rendered ("Mildred Island", based on GNIS data and matching exactly the imported node) doesn't seem to have an obvious match on Bing.

permanent link

answered 06 Jan '14, 10:37

SomeoneElse's gravatar image

SomeoneElse ♦
32.2k63333752
accept rate: 15%

-2

I am not answering my own question but targeting the quick and somewhat speculative answers, comments and especially the “vote” column in this forum. Well, I dare to do this even if I know I will get new down/negative votes.
As I understand, the OSM is a professional and scientific public project where arguments talk. So, there is no place there for filings based “like”/”don’t like” type of judgements and where any well-meant and constructive criticism should be welcome. Let me take some bullets:
1. If something is so frequently referenced/used as the SlippyMap (and its layers) by links, extracts and so on, then it is hard to deny that it is a reference map;
2. If someone just a bit carefully looks into the map-extract in the permalink (in the question) he may quickly find at least 10 island names assigned to water objects (rendered over blue background with no islands at all). This fact is so obvious and unquestionable argument in favour of a systematic error assertion that any excuse (like “looking from high above”) is simply speculative. You may “don’t like”-it but never qualified as “not useful” (eventually “don’t understand”);
3. If someone is even more careful, patient and curious he may discover that all the missing islands (holes in water area objects) are actually there. Unfortunately, some of them are inverted to water objects while most of them are overwritten by another water area data layer. And again, this unquestionable systematic error warning I may “don’t like” but never qualified as “not useful”;
4. Finally, this forum is probably the most visited among all OSM lists/forums. Therefore, a warning about a serious systematic error here may trigger the attention of many local editors and renderers. In my opinion, this may be of much larger help than just correcting several errors from the error class.
But still, I may be wrong.

permanent link

answered 09 Jan '14, 13:57

sanser's gravatar image

sanser
665353653
accept rate: 5%

2

As far as I can see there is one main problem: Instead of "misplaced names" there are lots of broken or incorrectly/insufficiently tagged multipolygons (according to Bing). They lead to islands being wrongly rendered as water / water wrongly rendered as land. Consequently also the names seem to be incorrectly placed, although they are not. Besides, each name relates from a place=island node. So even if the names would have wrong positions then you could just move the corresponding nodes to the correct position. But here the water/land polygons have to be fixed before doing anything else.

(09 Jan '14, 14:39) scai ♦
2

@sanser - I don't understand what you're trying to achieve. OSM is a do-ocracy; if something's wrong, go and fix it. Just pointing at something and saying "that's not very good" won't acheive a lot.

(09 Jan '14, 15:12) SomeoneElse ♦

also remember that sometimes things are more complex, so it's hard to evaluate the best solution from afar. for example, Mildred Island is labeled in the middle of the river. if you look at the imagery, you can see what appears to be the outline of an island, but it's now inundated with water. yet, is that still called Mildred Island even though it's more like a reef? and, does the island still appear when the water is under a certain level? if you can find the answers to questions like this, maybe we can help you figure out a better solution.

(09 Jan '14, 15:28) neuhausr
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×389
×42
×17

question asked: 03 Jan '14, 20:32

question was seen: 7,713 times

last updated: 09 Jan '14, 15:28

powered by OSQA