[Imports] Fwd: UN Mappers import of UNSOS waterways in Somalia
Rafael Avila Coya
ravilacoya at gmail.com
Wed Apr 8 15:08:08 UTC 2020
Thank you for sharing your feedback.
Please, find my comments inline:
>> Hi Rafael,
>> I have done a lot of manual river mapping in Somalia and Somaliland and here are some remarks how I did it:
>> - almost no river I mapped as perennial
>> - most of the rivers I mapped with intermittent=yes
Yes, I agree. The huge majority of waterways in Somalia, and more
specifically in Southern Somalia, are intermittent. Many of them are
wadis, most of the time dry.
>> - the ditches or drains I mapped were ditches leading to farmland for irrigation or leading to reservoirs (so called 'berkads').
Yes, and I would go for ditch better than drain. It's very rare to see a
lined drain there.
>> - all other waterways I mapped as stream or river, distinguishing both more intuitively than by a fixed width.
Although the osm wiki is the reference, all import is left in the hands
of the users, both mappers and validators. And this includes deciding
between river and stream.
>> - I don't remember having mapped a canal
If any, it's very rare. Agree!
>> - Riverbeds I mapped along some rivers where I thought it might improve the understanding of the topography for the reader of the card
There is another data set of riverbanks, that again covers the same
south Somalia area. It consists of 41 relations, 626 ways and 130k+
nodes. It's of good quality too, and very interesting to import. But I
considered it is better idea not to mix with waterways to avoid
complicating too much the workflow. We can prepare that import as an
independent import, that can go in parallel to this one.
>> - when flow direction was unclear if added a fixme
Good point! I will add it to the import wiki and to the workflow wiki.
>> - for waterways ending somewhere in the desert or before reaching the sea shore I tagged the ending point with waterway=stream_end. Josm validator doesn’t know this tag and throws a warning that I ignore.
And this one too! I will add it to the wikis.
>> - Crossing points of unclassified or higher class highways and rivers or streams I mapped with ford=yes; for tracks and paths I didn’t do that consequently.
I think we should do that with all highways for this import, to be
consistent across users. Including paths. But bear in mind that
sometimes rivers are crossed with a bridge. Sometimes we can find a
culvert. I will add that to the wiki.
>> - Highways crossing a broad riverbed: I tagged the part of the highways that runs through it with ford=yes. I did this wether I mapped the riverbed or not.
And this is good practice too. I will add it to the wikis. In fact, as
this import will ask for experienced users, I was already expecting
this. But I will nevertheless write it in the wikis.
>> - for highways inside a riverbed I did the same
>> For the workflow you are defining, Rafael, my additional suggestions are:
>> - describe how to handle stream_end
>> - describe how to handle the crossing between the imported rivers and the very old and wrong highway-data in the area ( we were talking about it before)
Yes, those Mart Roumen things... I will write something about.
>> - describe how to use ford=yes
>> - describe how to handle ditch or drain
>> - decribe fixme for unclear flow direction
>> So far my 5 cents.
Thank you so much again,
>>> Am 08.04.2020 um 12:42 schrieb Rafael Avila Coya <ravilacoya at gmail.com>:
>>> Hi, Christoph:
>>> Thanks to your questions, I've consulted the info about the original tags, and I've found some info that can improve the data to submit for import to the users.
>>> ACC takes only 2 different values: "1" means accurate and "2" means approximate. But almost all of the 44,360 ways take the value "1", and only 45 take the value "2". So I guess we can safely ignore it. Not ignoring it would mean adding a fixme="please, check geometry accuracy" tag to those 45 ways. Easy to do, but I don't know if it is worth. I've checked all of them, by the way, and the majority will be simply ignored (deleted) during the import process.
>>> ACE_EVAL has the value 21 for all ways. It's meaning is "FZD: Evaluation deferred", so we ignore it.
>>> ALE_EVAL values don't give any info at all. Ignored.
>>> F_CODE and FCSubtype are equivalent. The values are:
>>> F_CODE;FCSubtype;Meaning;Number of ways
>>> I've checked many objects with FCSubtype="1", and they appear to me to be more ditches than canals in the majority, so I would rather tag all "0" and "1" occurrences of FCSubtype with waterway=ditch, asking the users (as with all waterways) to decide if that tag is correct for each waterway in the workflow wiki.
>>> As for the rest of the ways (42,052), they will be tagged as river or stream by default according to the tag HYP as already told in the wiki, and with users deciding if changing its value or not during the import.
>>> FUN has only one way with value "Fully functional", so we ignore it.
>>> HYP has, as already said, 3 values:
>>> 1 = Perennial (267 ways)
>>> 2 = Intermittent (3,294 ways)
>>> 4 = Dry (40,799 ways)
>>> This will be difficult to translate to OSM tags. If any, I would put intermittent=no for the HYP="1" ways, and intermittent=yes for the rest. And then users deciding. Any thoughts on this?
>>> LOC has only one way with the value "44: On surface", so we ignore it.
>>> NVS has only one way with the value "0: Unknown", so we ignore it.
>>> SRC_NAME has 3 values:
>>> "0", meaning "Source is not known". 139 ways have this tag.
>>> "110", meaning "Very High Resolution Commercial Monoscopic Imagery". 9,321 ways with this tag.
>>> "112", meaning "High Resolution Commercial Monoscopic Imagery". 34,900 ways with this tag.
>>> I've checked the 139 ways. They are most of them very short segments, that don't present any problem, and can be checked against imagery. So I would rather ignore the SRC_NAME tag.
>>> UPD_NAME has 2 values:
>>> "0", meaning "Source is not known". 139 ways have this tag.
>>> "998", meaning "There is no possible value in the attriubte range that would be applicable. (May occur when the attribute is not applicable to the feature type (for example: the Airfield Type attribute of a Settlement feature type).)". All the rest of ways (44,221) have this tag. I would therefore ignore this tag.
>>> ZVAL_TYPE: All ways have 2 values: 139 ways have the value "0" = Unknown, and the rest (44,221) have the value "3" = Feature is 2D only. So it gives us no interesting information, and therefore we can safely ignore it.
>>> Cheers, and thank you very much again for your feedback,
>>> O 07/04/20 ás 17:45, Christoph Hormann escribiu:
>>>> On Tuesday 07 April 2020, Rafael Avila Coya wrote:
>>>>> Hi, Christoph:
>>>>> What do you mean when you say that it lacks any information on the
>>>>> provenance and specifications of the source data?
>>>>> As explained in the wiki, I am saying that the data is coming from
>>>>> UNSOS, using SPOT imagery. You can download the data under data
>>>>> source site, in the Background subsection of the wiki.
>>>> I am sorry for being unclear - i was meaning:
>>>> * what is the meaning of the various attributes in the source data?
>>>> Normally data sets like this come with a specification document that
>>>> tells you what for example an attribute like FCSubtype=* or HYP=1 is
>>>> meant to indicate.
>>>> * how has this data been created from the SPOT imagery mentioned? Was
>>>> it produced with some kind of AI algorithm? Was it traced by by
>>>> humans? If the latter was it done by people with local knowledge of
>>>> the area or by people from abroad? What was the original intended
>>>> purpose of generating the data?
>>>> There are various peculiarities that can be observed looking at the data
>>>> but i am reluctant to draw any conclusions or make recommendations
>>>> based on these observations without knowing how the data was produced.
>>> Imports mailing list
>>> Imports at openstreetmap.org
> Imports mailing list
> Imports at openstreetmap.org
More information about the Imports