[Imports] RFC for City of Basel Suburb Import

Rafael Avila Coya ravilacoya at gmail.com
Fri Dec 29 20:47:38 UTC 2017


Hi, Johannes:

Please find my comments inline.

On 29/12/17 14:32, Johannes Singler wrote:
> Hi Rafael,
> 
> thanks for your feedback.
> 
> Am 29.12.2017 um 06:22 schrieb Rafael Avila Coya:
>> Hi, Johannes:
>>
>> Thank you for this work.
>>
>> I have just small questions about the import.
>>
>> I am not swiss, so I am not going to doubt that suburbs don't have 
>> administrative significance, as you say in the wiki. But a bit further 
>> down in the wiki you say "We will not import the neighborhoods 
>> ("Wohnbezirke"), as some of their names are not familiar to the 
>> general public, but seem to exist for administrative statistical 
>> purposes only."
>>
>> So my understanding is that neighborhoods have some administrative 
>> use, and so I find it a bit strange that suburbs, that are higher 
>> level than neighborhoods, don't have any administrative interest (not 
>> even statistical).
> 
> Both are used for statistical purposes by the administration, the 
> suburbs even more so.  However, there exist no political institutions 
> for suburbs/neighborhoods (at least not consistently), that was the main 
> argument on the Swiss mailing list.  But maybe we over-interpret the 
> term "administrative" here, it does not read "political" after all.
> 
> @Simon, what do you think?
> In Bern, we have admin_levels both 9 and 10.  Okay, for 9, there exist 
> "Quartierkommissionen" as political institutions (except for the inner 
> city), but I don't know any political institution for admin_level 10 
> (e.g. Breitenrain).
>

Maybe you are being (or were being, cause you have already uploaded the 
data with boundary=administrative) over-interpretative. I guess we don't 
need a political institution in an administrative division to be 
considered administrative. Just if it has administrative interest would 
suffice.

I've seen a total of 137 administrative divisions in Switzerland 
(already counting the Basel ones) with admin_level=9, and a similar 
number for admin_level=10. So my opinion is that tagging them as 
boundary=administrative + admin_level=9 is the optimal solution.

>> Also, in the boundary=administrative wiki [1] it gives admin_level=10 
>> for neighborhoods in Switzerland, so it might be admin_level=9 or so 
>> according to the wiki?
> 
> Sure, admin_level=9 would be the perfect fit.
> 

Ok then.

>> In case of continuing with that tagging, I guess the suburb segments 
>> should have a boundary=suburb tag (they come with no tags in the osm 
>> file you share).
> 
> True, I forgot that.  However, the suburbs share many segments with 
> higher-level administrative boundaries, should those then have the tag 
> twice, or two semicolon-separated values for the key?  One more argument 
> for using boundary=administrative, it seems.
> 

The rule is that each segment should have as admin_level the highest 
level of all the admin divisions it belongs to. All inner suburb 
segments lacked the admin_level=9 tag, so I've just added it now [1].

>> boundary=suburb, as a new tag, should be documented in the OSM wiki, 
>> in case it's finally decided to continue with that tagging schema.
> 
> Well, it says "    All commonly used values according to Taginfo" there, 
> and "suburb" is used in other places already.  "statistical" would be an 
> alternative that is used even more often already.

I was meaning that boundary=suburb wasn't, afaik, documented.

But place=suburb is, althouth it's another thing (same value but for a 
different key).

> 
> Overall, the simplest would be to just use boundary=administrative 
> instead of boundary/place=suburb.
> 
> Another argument against place/boundary=suburb is that the suburbs do 
> not appear in address searches, e.g. "Terwijde" does not appear for this 
> search:
> https://www.openstreetmap.org/search?query=oskar%20nedbalhof#map=19/52.10646/5.03946&layers=N 
> 
> 
> Johannes
>

Although a bit off-topic, I have seen that all boundaries in Switzerland 
need some corrections. When looking at level 9 entities, I checked for 
example Jorat-Menthue (admin_level=8), in District du Gros-de-Vaud (6), 
Canton of Vaud, that is divided in 5 admin_level=9 entities. I saw that 
this Jorat-Menthue is duplicated (2 relations) [2]. It would be nice 
that an experienced user of the Swiss OSM community has a check 
nation-wide to correct this and other errors.

[1] https://www.openstreetmap.org/changeset/55019451
[2] Jorat-Menthue (1): https://www.openstreetmap.org/relation/1868685
     Jorat-Menthue (2): https://www.openstreetmap.org/relation/6857388

Cheers,

Rafael.

>> Cheers, and have an excellent end of the year,
>>
>> Rafael.
>>
>> [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
>>
>> On 28/12/17 14:42, Johannes Singler wrote:
>>> Hi everyone,
>>>
>>> after discussing this on the Swiss OSM mailing list (talk-ch), I 
>>> hereby announce the import of the suburbs of the city of Basel in 
>>> Switzerland.
>>> The one-time import is manual and comprises 19 suburbs.  It touches 
>>> three country borders, though.
>>>
>>> The import wiki page can be found here:
>>> <https://wiki.openstreetmap.org/wiki/City_of_Basel_Suburb_Import>
>>>
>>> I'm a local mapper living in the area.
>>>
>>> Looking forward to your comments,
>>> Johannes
>>>
>>> _______________________________________________
>>> Imports mailing list
>>> Imports at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/imports
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
> 
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports



More information about the Imports mailing list