Hi, Arne:

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
Good.

For the workflow you are defining, Rafael, my additional suggestions are:

- describe how to handle stream_end
I will
- 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
I will.

So far my 5 cents.

Regards

Arne

Thank you so much again,

Rafael.







Am 08.04.2020 um 12:42 schrieb Rafael Avila Coya <[email protected]>:

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
BH020;0;Ditch;1
BH030;1;Canal;2,307
BH140;2;River;42,052

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,

Rafael.

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
[email protected]
https://lists.openstreetmap.org/listinfo/imports

_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports

_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports

Reply via email to