Render place names from both points and polygons #2816
Conversation
This requires UNION ALL for the queries and an interior placement.
Actually, I don't necessarily agree with these statements. It all depends on how the rendering is setup, and I am pretty sure there are cases (my renderer is one of them - but I am pretty sure there are many other use cases), where this will likely complicate, rather than make it "much easier for developers", to display this most basic of OSM data: "places" and their names. Especially in GISs and CAD systems, this will likely require extra layers and render rules to display the "places", as generally, these systems require a single feature type per layer. The SQL UNION ALL wizardry employed here in the pull to unify or combine points and polygons, while nothing special for a DBA, is probably well past what basic OSM users using systems like QGIS, are familiar with. Having a consistent global point dataset for inhabited named places, is still of much value I think. This pull may lead to loss of many of the current tagged place nodes. By the way, in general I am not against support for multiple feature types for a single object type. That is just OSM and the different levels of detail it contains. This is just the one case where I think having a single consistent set of nodes for all places, is of high value. Places, besides roads, are just the core of OSM... In fact, personally, I would much rather see a proper tagging proposal that implements a "compulsory" tagging of BOTH nodes and closed ways / MPs for all named inhabited "places", so that we have a consistent synchronized set for both, and OSM data users/consumers could choose the data types they want or need for their purposes, rather than to have to deal with multiple in all cases. It is a bit ironic that we always talk about OSM being the "database", and that the database is more important than the actual arbitrary rendering, but the requests and arguments that led to this pull, and especially the desire to "de-duplicate" to avoid double labels for inhabited places, is more about the rendering rather than the database and its usage (of course, rendering a map and using the rendered map, is also a proper usage, and in that context de-duplication of labels is entirely valid!) |
Dealing with both points and polygons being used to map a feature in OSM is something virtually any data consumer needs to be able to deal with. If they can't, they're going to be unable to handle any of the features which can be mapped as a point or an area, including most POIs. |
Yes, I basically agree with this. However, the specific case of places, already requires some pretty complicated render rules to be able to display them in a sensible way across the wide range of scales place names are generally being used. Dealing with e.g. a church as node or closed way that is likely only displayed in a single font size and style in a very limited high zoom scale range (e.g. Z17-Z20), is far easier than the rendering of the places, that need to deal with different hierarchies and things like population and capital status. Anyway, my main concern is that this change currently only seems to have had real traction and discussion on this Carto repo, while there may be a wider audience interested in / or having interests in this subject. This is less concerned with this specific pull request, but rather the notion that people have already announced probably fairly large scale removal of place nodes, which also in worst case scenario might lead to edit wars... What I am actually maybe want to say is: wouldn't it be wise to widen the discussion a bit, e.g. on the tagging mailing list, before this pull is rushed into production? |
Even within the context of openstreetmap-carto, we already assume this level of complexity, and it has to be handled by data consumers in general all the time. For example, leisure=park has documented logic for both node and way rendering, and osm-carto renders both. 'How do we know where a park is, whether a node or an area?' We have answers for that (either green rendered text for a node, or an area, rendered in green, with text inside it). So does Nominatim (reverse geolocation to describe the center point of an area, which it calculates based on the way points, for example, https://nominatim.openstreetmap.org/details.php?place_id=173613917 ).
I appreciate the sentiment, but this isn't the place to try to enforce this. osm-carto isn't responsible for tagging standards inside OSM, and never can be. The only choice available to a rendering engine is whether or not to render what exists, thereby exposing the tags and node/way/relation structures underlying them. My vote here is to render these, and let discussions with those other groups fall where they may - but by all means, that interested parties should participate in them. |
|
To reply to the person who posted above, the 'vote' amongst the community has already been taken, in the sense that in a de-facto sense, both place nodes and areas are acceptable structures. iD and JOSM for instance consider both to be completely acceptable edits. There's no controversy - We could, sure, give a courtesy mail to the mailing list to tell them that we're going to start rendering a structure that was agreed on long ago by editor consensus, and that really should have been rendered as of years ago, but that's kind of what this comes down to IMHO. 'This is happening, heads up', not 'Should this happen?' |
This is not entirely true. Up to now, as there was a fairly consistent set of place nodes, consuming just the nodes, was enough. This allowed for a low level easy way of consuming and displaying them in any type of application. This may change as consequence of this pull. In addition, and again I agree "places" is not one of them, some features are explicitly defined as a single type in the Wiki, e.g. only node, or way.
Yes and no, I have seen the Carto team members responsibly discussing time and again the potential consequences of certain changes for the database and tagging practices, and the concept of "mapper feedback" and the relation with styling, and this specific de-facto "main" style.
I am not concerned so much with the acceptability of place as both nodes and ways, because I basically agree with you that the Wiki allows this, but my main concern is the announcements I saw that people will remove existing nodes / features, just to clear up what they consider "clutter" of double labels in the map. I just want to point out that there may be data consumers who rely on this information that is going to be removed. Again, for most features, I consider this a non-issue, but places are so much "core", I think they warrant a bit more attention... |
And this will make it easier, because people won't have to worry about deduplication. I often hear negative feedback about the current state of duplicate place data, and efforts people are forced to go to to deal with it.
If someone wants to forward the fact we have this PR to another venue to get more feedback here, that's always an option. I'm satisfied with the level of discussion we've had in the parent issue, and what I expect we'll get here.
Yes. Currently it is acceptable to map a place by just a point or just an area, and this will remain true. |
|
It sounds like this doesn't require a full stop halt of this PR, but may want two things to happen, which I think are quite reasonable Things:
If those two things are done, does that address the mechanics of those social problems? |
|
I notice they seem to be used together for a couple of reasons:
Is there a way to combine them using a relation to take advantage of both nodes and areas? |
|
We have an admin_centre role in relation boundary, so probably place_centre might be defined for place relation. |
|
@boothym 's use case is essentially covered by the 'label' relation member in a Key:boundary relation. For those, all place related tags (and the That said? All of this is a different RFE, and shouldn't be paired with this PR - it's another way people do this, but it's a completely separate use case. (If that issue doesn't exist? Sure, it probably should be created as an RFE.) |
|
I still think that this thread is dominated by those who potentially benefit of this solution, in the narrow context of only considering the postgis / osm2pgsql / openstreetmap-carto / mapnik rendering tool chain. Again: I am not against places as way objects by themselves, they are valid. However, the removal of place nodes to de-duplicate, may pose issues and potentially seriously complicate the use of basic place data by other OSM data consumers. Personally, I would much prefer a solution that maintains current nodes tagged with place=X, and combine them with some representation of places as ways/MPs in a relation (the way/MP not necessarily tagged with place=x but potentially using another tag - "boundary=place"? as I think someone suggested... - this would avoid duplication). I do think more voices need to be heard on this potential high impact change for a more nuanced view on this: @gravitystorm , @imagico , @matkoniecz , @lonvia, @mmd, @woodpeck , @joto, @zerebubuth, @tyrasd , @wonderchook , @pa5cal |
The Talk and (probably even more) Dev lists seem to be the natural platform to get more input on the subject. |
|
Wrt duplication, to reiterate: Place nodes and place areas are not the same thing. Place nodes describe the economic center of a place, so to speak. They are not necessarily the same as the geographic center and cannot be computed easily from areas. It is a useful feature for any software that needs a point feature for a place. The most obvious usage examples is with routers, where you really want a route from center to center when asking to go from, say, Berlin to Munich. Encouraging people to remove nodes where areas exist, will remove this important information. As a side effect, this PR is also eventually going to do damage on admin relations. These currently have the place nodes with the label/admin_role exactly for the reasons stated above. This happens to work out fine even when admin boundaries are treated as standard multi-polygons where all ways are treated as belonging to the boundary. When as a result of this PR place nodes are deleted and place areas are going to appear in the label/admin_centre roles, the multi-polygon treatment will break without special handling for boundaries. I am highly opposed to that, see osm2pgsql-dev/osm2pgsql#678. Finally, note, that place tags often appear on admin boundaries when the official admin_level does not map to the common place designation. Prominent example is Germany, where a place=city can have admin_level=4 (Berlin), admin_level=6 (Mainz) or admin_level=8 (actual town admin level). I would not consider that incorrect tagging as implied by @pnorman in the original comment. |
|
I am coming into this discussion a bit late after @mboeringa added me and am struggling a bit to understand all the details. If I understand the discussion correctly there are two ways people are tagging places:
Historically only the first was rendered in osmcarto and @pnorman wants to change this to render both. This would, in theory, allow everybody to either tag using option 1 or option 2 and all is well. In addition if both options are used at the same time this would show up in the map as duplicate labels which mappers would presumably fix. Some observations here:
Together this leads me to: What we have been doing all along is fine. Just make it more so: Remove place tags from admin relations and we should be okay. Set up a few consistency checks and show this info in checking tools. |
This is incorrect. This pull will not merge place nodes included in admin relations with "simple" place nodes. This pull will merge closed ways and multipolygons tagged with place=x with nodes tagged as place=x (which could be part of an admin relation, but this is irrelevant for their rendering, they are already rendered AFAIK). The merge is done using the UNION ALL SQL operator. |
|
@mboeringa Now I am thoroughly confused. Why are there place tags on "random" areas (closed ways or multipolygons)? I could understand if they are on admin relations, but why on other things? That's just wrong. |
@joto The Wiki page of place allows both "random" closed ways and nodes as valid feature types, see: "You may also define a boundary for a place by creating an Area and tagging it with the place=* tag." |
|
Think of place tag as a generic indicator of some named places - be it a continent, a town, a farm, an island or a square, which are not always defined by any kind of administration. |
What strongly encourages tagging for renderer and as result I would not consider it as a positive effect. |
I don't see this as big issue in the rendering based on current render results. Also, this is not about wrong tagging, e.g. using a certain tag just because the render result has nice color... This is merely about the placement of a place node, which is by definition quite arbitrary (unless the town or city in a rare case happens to have some stone cemented down on the main square stating it's the urban centre!), it is not comparable to a natural=tree or amenity=bench that has some fixed recognizable location. I also think @lonvia 's remark about placement does make sense in the context of urban areas. While for something like an industrial zone, the exact outcome of automatic placement inside a polygon is largely trivial, a place's name label usually cartographically and socially / urbanisticaly has some preferred location, e.g. the square in front of the townhall. This will rarely coincide with the automatic placement inside a polygon. |
I would say that
Re: (2), I tried showing a valid use of using place on an area that represented a citable/verifiable population census CDP boundary months back, and got blowback amounting to 'The government defined that population center poorly, why would we render it the way they designated it? 1 (I would argue that it's not our place to pass that judgement in the context of the map render.) Re: (4), this is where I found that #105 (Support rendering of "label" member of relation) was strongly objected to by gravitystorm: GS's take seemed to be that relation members should not exist to provide rendering guidance, and this task should be taken care of by the renderer. In any event, since #104 never was addressed, the current method of rendering the name of an administrative boundary in this manner is none, so using |
|
Back to this pull request: Considering there is also a pull for adding shading / fill to place areas #2806 , there is another question that comes up: Do we actually need to render labels on polygons (closed ways / MPs), as this pull attempts to implement? There is the secondary option of only shading the place areas, and use the nodes to label. This would effectively result in almost the same rendering, yet avoid dropping nodes and potentially trashing existing usage and boundary administrative relations. I think this is the only reasonable and realistic compromise in this situation... although I see on that thread that some of the people who expressed favour of rendering the labels as per this pull, are not in favour of actually rendering the area with a fill or shading...?? (@kocio-pl: #2806 (comment) ,@matkoniecz: #2806 (comment)) |
You describe the node as being primarily a relation member. While not incorrect, I think it more realistic to describe the node tagged with place=x as being an independent entity, that was subsequently added to a boundary administrative relation (this is the usual order in which this happens, first a place node is added, and with further editing users start adding boundary relations in an area).
See my #2816 (comment) to @matkoniecz , I don't think this really classifies as "tagging for the renderer". Place tags are valid here, it is not comparable to using a random tag to display a specific color or symbol that a user likes, regardless of the tag description describing an entirely different object. |
|
I too have only just come into this discussion, after seeing a reference to it on the tagging list. I am in agreement with joto (two options bad), kocio-pl (where no administration exists) and mboeringa (arbitrary positioning of name) I am very much in favour of separating the place name from the boundary as the boundary in many parts of the world is unknown and will remain so for many years to come. This results in mappers putting the name on the residential area polygon in the mistake that it is the extent of the town/village/hamlet. Having the place and name on a node placed in or at the central hub of the town/village/hamlet will meet the requirements of routing, will render on the map in a far better location than being arbitrary centred from the polygon or boundary relations. This will also give a far better positioning when zooming in or out. We can then add attributes of that place to the node that will help many other users to use our database in a far more intelligent way. The separating of the name will also work for other polygons such as schools, parks, industrial centres, and even national game reserves that require names of multiple tourist villages/camps (which do not have an administrative or official boundary) within the boundaries of the reserve. As with large farms the map users expect the name of the farm to be near the cluster farm buildings and not floating out somewhere in the middle of a field centred inside the farm boundary. Even the postal code/address entered into a SatNav will take them to the farm buildings, not the centre of the farm area. Removing the node will take away our ability to name a place when the boundary is unknown but the name of the place is known. It will also mean that many areas in rural Africa and southern Asia will lose their place names as their boundaries there are not known, leaving blank patches, thus removing an advantage we have over many other forms of online mapping when we put these vulnerable and isolated places on our maps. |
|
I was planning to stay out of this but I must reply to @RAytoun who seems to have misunderstood the situation. Nobody in this thread has advocated the removal of nodes where no polygon exists to replace it, as @RAytoun seems to suggest when he writes "many areas in rural Africa and southern Asia will lose their place names as their boundaries there are not known...". Whether a place is "vulnerable" or "isolated" is completely orthogonal to this discussion. |
@mboeringa : Agreed on the general principle. I looked at the site; given that that SOTM 2019 is 9 months away, it might be a good strategy to go with this:
|
|
@gravitystorm This is a good example of an issue where we, after more than a year and 116 comments, we fail to find consensus. Some comments that offer a good summary of the discussion: @gravitystorm Do you have any suggestion on how to proceed, or how to handle such situations in the future? |
The sucess and good participation (more tham 70 contributors) of the project is the collective decision... People remain engaged when they are heard. But sometimes consensus is impossible: this issue is a good example where we need some "trigger" (some governance rule) to open a formal votation. |
I've gone back and forth because I can see both sides of this issue, but I am now against merging this PR. I am going to close the PR, because as a PR with merge conflicts where the author will not be fixing the conflicts it needs closing. |
|
So is anyone going to find a solution for this, or are we screwed forever? One more example (not directly with osm-carto): after mapping the suburbs of our 1-million-people city as areas, I mapped additional toponyms for smaller areas as neighbourhoods, and given all the pushback I've received here, I used nodes. The result is that when you look for streets in Nominatim, they get attributed to the wrong neighbourhood, because Nominatim can only look for the nearest node, which is not always the right one. I suspect that if I mapped neighbourhoods as areas Nominatim would get it right... I can see that a more global solution, rather than just changing the way osm-carto works, could be desirable, but... is anything going to happen? Thanks, |
|
@vbertola actually the "global" solution is not the problem, it is just that the normative effect of the standard style is so large (for good and for bad, see #371 - #214 for an example of this style promoting mistaken tagging because of rendering) it doesn't make sense to introduce well visible tagging changes without support by the maintainers. |
|
Even though the ticket is now closed, I would still be interested to hear @gravitystorm's ideas on how to manage tickets like these. |
|
@vbertola current solution (for the last ~10 years) is/was to map administrative boundaries (boundary=administrative+admin_level=x) as polygon and then place a node (place=x) where you want a label for that administrative region to show up. (You may add place node in admin boundary relation with a role admin_centre). |
|
@simonpoole - i don't really get your point here - no one will seriously doubt the influence this style has on mappers, the responsibility resulting from that and that there are decisions where this style does not live up to these requirements. But this particular issue is not a case where this applies - on the contrary, it is an example that responsible decisions are still possible. @vbertola - as always the suggested approach is:
Note the discussion here was was mainly about rendering of the sequence |
I simply wanted to point out that without a commitment by the maintainers of the style to at least de-duplicate names for areas and nodes for the same place there is unlikely to be any movement, as the concern (#2816 (comment)) that started off this lengthy thread would still be valid. An agreed on area + node place scheme wont do away with this requirement as fas I can see. |
|
To put it in a very simple form: Mapping populated places with nodes is done consistently in OSM at the moment - except for some inflationary classifications (hamlets in remote areas tagged as cities etc.). Therefore these are rendered by this style. This style supports mapping populated places with nodes tagged place=city/town/village/hamlet because of a consistent mapping practice. Polygons tagged with place=city/town/village/hamlet are mapped without any significant level of consistency. Sometimes they represent administrative units, sometimes aggregates of urban land uses and sometimes they are abstract hull drawings grouping buildings. And this fact is documented on the wiki. This style does not support mapping populated places with polygons tagged place=city/town/village/hamlet because there is no consistent mapping practice for those. And as i see it this is also exactly what the documented goals of this style suggest. I am not sure what kind of additional commitment you expect. |
|
sent from a phone
On 5. Jan 2019, at 12:37, Tomas Straupis ***@***.***> wrote:
@vbertola current solution (for the last ~10 years) is/was to map administrative boundaries (boundary=administrative+admin_level=x) as polygon and then place a node (place=x) where you want a label for that administrative region to show up.
no, places do not require administrative entities. You can add places for example for settlements, without there being a corresponding admin object.
|
|
The solution pointed out by @tomass is the one I used for suburbs, except that our suburbs are not formal administrative divisions, so just type=boundary with no boundary and admin_level tags. But then, why doesn't the wiki just say "if you need to map places as areas because they have well defined borders, do it this way"? That looks like a current "consistent mapping practice" (as @imagico wants) that everyone would support. Or am I supposed to just go and edit the wiki to add it? However, I note that in all the nearby cities that I checked, such as Milan or Lyon, people used this solution but added place=suburb both to the admin_centre and to the relation, so I did the same; but I don't know if this creates double labels in other renderers. It would be just easier if the people leading the development of the most commonly used renderers (and Nominatim) met in a room and agreed on a clear solution for mapping places as areas that worked consistently in all the various pieces of the platform. |
|
@vbertola - these are matters that are better discussed on the tagging mailing list. |
So I've read a little of this topic, but I don't think it's all that important that I fully understand it in order to answer your question. It seems like there was no decision by the maintainers as to what the best solution was, so we would need to help the maintainers come to a collective decision. So the first step of reasoning would be - was the lack of decision because:
or
Note that here a 'solution' could mean to reject the PR, approve the PR, or approve the PR in principle, but pending certain prerequisites (from external projects, like changes to osm2pgsql or tagging presets or whatever), or other approaches. I feel like a common problem is that if the topic becomes too complex, and the pros and cons are not clear to an individual maintainer, then super-long threads don't help decisions to be made. This is because people can (naturally) change their mind when more information is added to a thread, and trying to figure out the whole situation by reading the thread with 100 viewpoints is like having to mentally apply 100+ "patches" to your own mental assessment of the topic. So perhaps on some complex topics we need more fleshed-out proposals, rather than long lists of comments. Many projects calls these RFCs (or similar) to mean Requests for Change, but in short we could have a proposal that is edited and reworked as necessary, until it gives a full picture of the proposed change. That could help the maintainers to make decisions more easily, or if there is deadlock, help other maintainers get up to speed with the topic. Of course, if the problem is that the proposed change is easy to understand, but the maintainers are simply coming to different conclusions about the solution, then the situation is quite different and the topic becomes one of resolving disagreements instead. |
You are missing different kinds of place entities that are definitely not administrative entities, are not landuse equivalent nor dubious hull drawings, and that do have designated or otherwise well-defined borders. These are suburbs in some cities as pointed out a few comments above, also following has been mentioned in this topic previously: census-designated places in US and settlements in Estonia (including dispersed settlements with designated borders). There are also entities similar to census-designated places in other countries, like tätorts and småorts in Sweden. That sort of places to my understanding is the main use case for rendering place names on polygons. I've been trying to follow this topic, but I still don't quite understand how or why this type=place relation proposal came in. While it might be a useful idea, this seems to be irrelevant to given problem. If place name is rendered on polygons then it could render for all polygons. Whether multipolygon or boundary type is appropriate and ensuring that tagging is otherwise consistent, or that places are not mapped as areas when there isn't good reason to do so, should be up to mappers in given region, just like is the case with any other region specific tagging. I understand that names on polygons and nodes being duplicated would be a problem, but this to my understanding was solved by proposing a patch that, if I got it right, intended to filter out these duplicate names. To me this still seems like a decent way forward. I'm not hoping that adding my comment to this pile of comments clears things up, but still, maybe it clears things up a little. |
|
@Pikse - If there are a significant number of populated places mapped with polygons where the polygon neither represents an administrative unit of some sort, an aggregate of urban land uses or an abstract hull drawing that would just mean there are not only three different and inconsistent variants of mapping these places with polygons but more than three. That does not really change the situation. Note once more discussion here focused on place=city/town/village/hamlet and not place=suburb/neighbourhood. But just from a quick look at taginfo: suburb: 6.8k ways, 7.3k relations - 5.7k of these are administrative boundaries, 3k have a landuse tag it looks like the situation is similar for those. |
|
@imagico What do you mean by saying these are inconsistent variants of mapping? To my understanding this is how it works: there are different kinds of places, roads, hierarchies etc. in different regions and mappers in each region will figure out how to tag these so that it'd make most sense and it'd be as consistent as possible throughout the region. You say that place tag usage for nodes is consistent. I don't see why place tag usage for polygons couldn't be consistent in the same way, including for those among these more than three "inconsistent" variants that are currently mapped as both area and node. To my understanding the idea was to render name on all polygons with place tag regardless place type. |
|
This is not a case of regional differentiation. It is not that you can say in Germany populated place polygons represent administrative units while in France they are aggregates of urban land uses. A user of this data does not know which meaning it is for the individual feature so they cannot expect any meaning of these geometries. In other words: There is no usable information in this data. We do not want to support mappers in adding meaningless data. If you want to get a first hand impression just use (for towns): https://overpass-turbo.eu/s/F2H When mappers want to map administrative boundaries they should map administrative boundaries. If they want to map urban landuse they should map urban landuse. And if they want to map abstract hull drawings around groups of buildings - well, then they should not map anything and read up on verifiability. And they should all map place nodes of course. If they want to map something else about populated places then they should document a mapping concept on the wiki for that using new tags (and not re-purpose existing tags) and when mappers take this up and consistently map it we should try to support it in rendering. |
|
Examples that I listed above are actual places (types of populated places, settlements) with well-defined borders. Regardless whether the same place is mapped as node or area, usage of place=town, place=village etc. would be somewhat close to tag description, but either ways usage of these tags varies to some degree between different regions as in reality there are different kinds of places and different hierarchies in different regions. This does not mean that data is meaningless. None of these valid place examples is what you listed (administrative units, landuse, hull drawings around buildings groups). I agree that the latter either shouldn't be mapped as places or they should be mapped as only place nodes. To me it seems that ignoring regional differentiation is pretty much what misunderstaning here is caused by for the most part. Maybe in Germany or France there aren't places that should be mapped as areas (then just don't do it there), but this doesn't mean there aren't such places elsewhere. |
It was late, but @pnorman closed this particular PR in its current form, and this was after considerable deliberation of "pros and cons" reading his words, and the fact he was active in the thread for a long time as many of us. So I do think a decision was made (which I support personally).
I think the overall negative impact of this on many systems and uses of the data is what is ultimately the decisive factor. I think there is not so much discordance among those knowing and fully understanding the technical backgrounds. However, to make the issue more clear to those having little to no technical background into the ecosystem of software running OpenStreetMap, I have been trying to come up with an analogy that might help explain the potential impact of this apparent minor change, or the consequences it at least is likely to have. I want to absolutely stress that I did NOT write this analogy to ridicule anyone pleading for name labels on polygons. However, to make the point, it must be a bit provocative and confrontational. But this is meant with friendly "tongue in cheek". Just like Paul wrote, I can see both sides of this issue as well, and fully understand where the desire to see place polygon labels comes from. I just hope that by making this analogy, that people with less to no understanding of the technical background of many of the systems running OpenStreetMap, or the sometimes complex uses thereof, get some idea of the potential impact of the loss of a consistent point place node set. So, here it is, and keep my remark above in mind when reading...: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx We, as the people, now demand of you, the utility companies, to deliver all the commodities and services we were used to when living on the ground, to us now living in trees: we want gas, plumbing, sewers, electricity, and sure, our latest iPhone29 bought on the internet and send to us in a personally addressed parcel package, must also be delivered at our front doors 30 meters above ground, we won't come down to help you with that..., we know our rights! And we certainly don't want to see our house suddenly without running water or electricity, just because we decided to start living in tree houses, that is not our problem, you are the utility companies! Go figure it out and do it, it is our right, it must be done!" Unfortunately, the switch to a mixture of place points and polygons, with especially a likely removal of point place nodes to "de-duplicate" things, is such a "decision to start living in tree-houses"... Yes, sure, it can be done, but at what cost, and is it practical? The cost of a very likely loss of a single consistent, and easy to consume place node/point dataset, something @imagico also expressed well in one of its last posts. Professional cartographers or simply map enthusiasts who would like to have a dab at creating a basic topographic map of their area showing populated places now needing to consume ways and relations as well, and needing to merge them somehow. The potential disruption and issues for core services of OpenStreetMap like geocoding engines, potential problems with routing engines, all kinds of data analysis routines failing to come up with results, if they rely on the same consistent place node point dataset. Fact is, people have likely been relying on a rather consistent place node point dataset for quite some time in OSM, especially in the hierarchy of city/town/village/hamlet/isolated_dwelling. Lastly, I want to re-iterate here that I am not against places as polygons, only against place polygons as the sole source of part of a set of "de-duplicated" place name tags, with a "mixed" source of Points and Polygons without a consistent Point dataset as we now have. I think we need both points and polygons for the places in the city/town/village/hamlet/isolated_dwelling hierarchy for different parts of the software ecosystem of OpenStreetMap, and its highly varied uses by many different types of people, from the hobbyist (printed/digital) map enthusiast, to the hard-core software developers never bothering about a visualized and stylized map but just data and its analysis. |
|
@imagico Sorry Christoph But you are wrong on this, while the nature of settlements tends to be a bit fuzzy, that is not a reason to say that we can't make a best effort to map an extent of a place even if there is no formally defined border. It is a problem that all geo-data providers need to grapple with and pretending that it doesn't exist is not going to help anybody. As an example I offer the place I live in, it is part of a larger municipality, it has no formal border, but it does for example have an official name sign on the road leading up to it (so obviously it is not just a figment of my imagination). The Swiss Federal Office of Topography provides a polygon for the extent, so again not a figment of my imagination. And mapping it as an area would have numerous advantages, for example would avoid overlap with other places in the municipality, allow analysis of what is in the place (for example which streets and houses) and so on. PS: I don't think Germany is a good example in this case as their is wide spread use of fake admin boundaries to get around the issues we are discussing here. |
|
@Pikse - I don't know how i can express myself more clearly here. I explained what i see as the main reason why the decision we made here is the right one - you are not required to agree with me and you are also not required to agree with Paul closing this PR. If you have something verifiable you want to map and feel inclined to map it with a polygon and tag it place=city/town/village/hamlet i suggest you explain the situation you have on the tagging mailing list and ask for suggestions how to map this.
And where should i have said anything like that in the discussion here? |
Yes - and I also wrote the PR. If someone has comments about if we should render place names from polygons, they should go in #103. If they're about this PR, they can go here. |
|
I still had a couple of comments but I moved them to #103. |
Fixes #103
According to the description of the other PR, fixes #2804
This doesn't change the cartography, but reveals two errors in OSM data that have been showing up on other maps
== Incorrect city tags ==
There's a lot of areas with place=city on them in the US which shouldn't have it.
Because osm-carto doesn't show them, they've largely gone undetected, but show up as problems on other maps
== Duplicate places ==
Frequently there's places which are mapped as both points and areas
Again, this has been hidden by osm-carto, and is a problem for other maps.
Aside from the obvious fixing of #103, this will make us consistent with other maps and much easier for developers of other maps using OSM data.
This was done as part of my WMF work on https://phabricator.wikimedia.org/T163819