Changeset: 133806335
Quebec admin_level=6 (MRC/TE) 05 Estrie. Fix relation tags, members, boundary ways.
Closed by Graptemys
Tags
created_by | JOSM/1.5 (18360 Debian en) |
---|---|
source | ISQ |
Discussion
-
Comment from webfil
Greetings. I noticed that some of your changesets introduced discrepancy between the mapping guide available on the wiki for key:place (https://wiki.openstreetmap.org/wiki/Key:place) and the tagging or placement of objects on the map. For example, node 10742470936 (https://www.openstreetmap.org/node/10742470936) is labelled Cookshire-Eaton and tagged as a city. Let alone it is a duplicate of node 691128187 (https://www.openstreetmap.org/node/691128187), the value for the key seems inappropriate, as the population of the "urban" area is around 1,000 (https://www12.statcan.gc.ca/census-recensement/2021/dp-pd/prof/details/page.cfm?Lang=F&SearchText=cookshire&DGUIDlist=2021A0006240259&GENDERlist=1,2,3&STATISTIClist=1,4&HEADERlist=0), which does not meet the status for being "the largest settlement or settlements within a territory, including national, state and provincial capitals, and other major conurbations". The result is that a small village is labelled on the same level as a city such as Sherbrooke, which qualifies statistically as a metro area as its population exceeds 100k, and is the largest city in the Estrie region. As for the name, the place itself is named 'Cookshire', with the vicinity (villages and hamlets of Johnville, Sawyerville, Birchton, Eaton Corner and rural surroundings) being referred to as 'Eaton'. The postal adresses and road signage still refer to this place as 'Cookshire', for there are multiple villages and post offices within the boundaries of Cookshire-Eaton municipality.
I suspect that your intent was to map places accordingly to their statuses within the administrative hierarchy. If that is the case, I believe the key:place is not meant to identify the administrative status, rather to label the map with the name of localities. Boundary objects can provide for administrative levels and the value for key:administrative_centre in relations indicate the location of a county seat. Is there a discussion in the community, especially with the canadian an québécois users, that can support the use of the key:place that is made in your changesets?
This comment is also valid for changesets 134044806, 133980227, 133792913, etc.
-
Comment from Graptemys
Hi webfil,
In this change (and the others like it) I was focused on cleaning up the admin_level=6 (MRC) boundaries. I did fix issues when I saw them on smaller administrative areas but there are >1000 municipalities in Quebec so I didn't check every one. So there are definitely still issues or inconsistencies that should be fixed but it would be a big project.
I remember looking at Cookshire-Eaton specifically because it is part of an urban agglomeration while also being a part of an MRC, both of which are usually tagged admin_level=6. I made sure the city was mapped, but the agglomeration is currently unmapped.
I placed the Cookshire-Eaton node with a goal of having a node and a boundary relation for every administrative area, with matching name, and place tag on the node. There is not any guidance for that on the wiki but I have found that JOSM, osm-carto, and nominatim all seem to prefer it like that. And yes I did choose place=city because of the administrative status, not realizing how it would compare to Sherbrooke. That could be fixed.
I don't think that those two nodes are duplicates, given that the population center called Cookshire and the municipality called Cookshire-Eaton seem to be different concepts. However I would say the Cookshire node could be the admin_centre and Cookshire-Eaton node the label of the Cookshire-Eaton boundary relation. I'm not sure why I didn't do it that way in this changeset.
-
Comment from webfil
Hello again. I do not think your goal can be reached with this particular usage of key:place. This kind of object has to represent an actual, tangible geographic feature that is the settlement, while administrative boundaries represent some abstract, political features that often cannot be pointed on aerial imagery.
The documentation does indeed provide guidance on the relationship between admin_level and place=* (https://wiki.openstreetmap.org/wiki/Key:place#Relationship_with_admin_level) : if and when a place is also a level of government with the exact same extension, then a relationship with admin_level is to be made. Otherwise, since administrative entities contain areas outside the settlement, that is not necessary nor recommended. This the case for Cookshire-Eaton, since it holds some four villages; this is the case for Témiscouata-sur-le-Lac, since it holds two villages; this is the case for many more merger municipalities, town and cities.
I stand my point; this batch of edits is controversial, to say the least , and should be the object of a consensus throughout the community, especially with the fellow québécois editors with whom I have cleaned up the canvec data with regards to the guidelines ― I'm thinking of PierZen, Martin868, jfd553, etc.
-
Comment from Graptemys
Okay, please go ahead and make whatever fixes or changes you think are necessary.
- 394410154, v6
- 394410157, v3
- 394410158, v5
- 394410160, v6
- 544218540, v3
- Rivière Saint-François (544218541), v4
- 555005263, v3
- 555005299, v3
- 555005301, v2
- 555007075, v3
- 555007076, v4
- 555007078, v2
- 556904898, v2
- 556904910, v2
- 556904913, v2
- 556904914, v4
- 556904915, v3
- 556904916, v2
- 556904917, v4
- 556904926, v4
Relations (10)
- Brome-Missisquoi (7926989), v19
- La Haute-Yamaska (7927015), v11
- Le Val-Saint-François (7950471), v7
- Memphrémagog (7953108), v15
- Coaticook (7953154), v7
- Le Haut-Saint-François (7953227), v14
- Cookshire-Eaton (7953239), v3
- Les Sources (7997176), v9
- Le Granit (8064410), v18
- Lac-Mégantic (8064416), v4
Nodes (5)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |