Graham Asher's Comments
| Changeset | When | Comment |
|---|---|---|
| 164161393 | 9 months ago | Thanks! I believe I am an expert, because I've been working on map rendering since 2003, specifically my CartoType system (commercial but with free map creation, map display and routing apps), which uses quite a number of label placement methods including trying different positions. Mapnik is an open source renderer which moves labels around. Please google "mapnik label placement" to see several articles about what it does. |
| 164161393 | 9 months ago | Dave, I respect your point of view, but that's not how OpenStreetMap works or is intended to be used. And in fact there are areas (like central London) where many POIs and other things are almost literally on top of each other, because they are mapped in their actual positions. The renderer handles that by prioritising some labels above others, and by moving labels around. But we as volunteer cartographers map ground truth. Of course it is debatable where the 'true' centre of a village is, but the centre of the built-up area, or a road junction near that point, is always a better place than somewhere in a field outside the village. It's also important to map village centres properly because they can be used as destinations by routing systems. For further backup, please see osm.wiki/Good_practice, in particular the section 'Don't map for the renderer'. |
| 164161393 | 9 months ago | That's not recommended, and is an example of mapping for the renderer (i.e., second-guessing the renderer's policy). According to the wiki, settlements points should be at the centre of the settlement. The rendering software can then decide where to place the label. A label point to the east of a settlement would in any case cause a label at that position to overlap the settlement if the map was rotated; a common use case. |
| 29818328 | over 10 years ago | That's great. Kind of embarrassing to have the biggest natural lake in England disappear. |
| 29818328 | over 10 years ago | I think this change is incorrect. It seems to delete the entire outer boundary of Lake Windermere. The lake has indeed disappeared from the map as rendered by the OSM slippy map. Please revert. |
| 29278321 | almost 11 years ago | Hi Michael - please feel free to put the number back if you really think it is genuine, which I strongly doubt. The number 999 is often used as a special value for 'don't know' or 'not applicable'. It would be nice to have some independent evidence. |
| 26567938 | about 11 years ago | That's good. I'm glad the matter is now up for discussion, because it is a serious problem. My personal involvement arose from attempts at geocoding, where I very much needed to distinguish detached places from parts of conurbations. It would be marvellous if every suburb, city, town, and so on was mapped as a polygon, and the polygons nested properly and didn't intersect, but I know that will never happen. |
| 26783815 | about 11 years ago | Thanks for letting me know. I'll let you all get on with it; unfortunately I can't get involved in detail because I am too busy. I thought I was being helpful, and it's strange to have these small and guidelines-compliant changes described as 'sweeping', and me described as a 'self-appointed wiki editor' when (i) I didn't edit the wiki; and (ii) we are all self-appointed editors in OpenStreetMap. I agree that there is a problem with suburbs of different levels of importance, but I don't think it's helpful to tag suburbs as towns to solve that problem. I think we ought to be mindful of the distinction between ordinary language (when I lived there everybody called Highgate a village) and OSM tags, which aren't there to reflect that usage. |
| 26567938 | about 11 years ago | That seems an odd thing to do. It's perfectly clear from the tagging guidelines that 'village' and 'hamlet' should not be used for subdivisions of an urban area; 'local discussion' won't change that, and if inconsistencies are introduced because of local pressure that reduces the value of the map data as a whole. |