[Imports] UPLOADING U-WIMP project data to osm

Stellamaris Nakacwa sn00013 at mix.wvu.edu
Wed Nov 9 20:01:56 UTC 2022


Thank you, Mike. we are fixing all the key pair suggestions.

Yes, some points look like they were repeated but in fact, they were not.
>From the field validations, enough buildings such as institutional
buildings have more than one infrastructure in very close proximity. It
also happened to be a situation in some springs and with respect to local
knowledge, the mappers carried them as they learnt from the community
leaders.

Some water points also look like they are inside the building (we will
adjust that) a) because some buildings are multi-polygons and the points
are actually in that inside spaces. The others are on top (some tanks) so
with 3m precision, they end up inside buildings. However, the team is
remaining cognizant of all of that.

Overall, any attributes did not stand in isolation rather it is an
establishment of the entire distribution network, tagging which taps are
part of the municipality and which ones in isolation  (i.e. taps are of 2
categories, ones that tap from tanks systems (groundwater) and ones that
tap from the municipal pipes (surface-water) --All reviews are being done
by the validation team to ensure that it is all coordinated (importance of
the photo), however, this does not represent duplication to the
distribution network that is being captured.

Thank you!

Stellamaris





On Wed, Nov 9, 2022 at 9:36 AM Mike Thompson <miketho16 at gmail.com> wrote:

> Hello Stellamaris,
>
> Thanks again for providing the file.
>
> General Tagging Concerns:
> * There is still a source=* tag.  I think Frederick recommended that the
> source tag only be put on the changesets
> * There is no need to have a county=* tag, people will know what county it
> is in by its location.
> * dristrict=*, also probably not needed for the same reason, but if it is
> included, I think gulu should be capitalized because it is a name (unless
> gulu is the type of district and not its name).
> * fee=Yes (Y is capitalized), key values should generally be in lower case
> * operational_status=Decommissioned (D is capitalized) key values should
> generally be in lower case (except for names)
> * There are probably more cases of values being capitalized which should
> not be, please check
> * operator=* This tag should generally name the operator, for example,
> "Gulu Water District".  This dataset just indicates the type of operators,
> such as "institution", this probably should be in a operator:type=* tag [0]
> * It seems like there could be additional, or different, more specific,
> tagging used, such as for tanks (man_made=water_tower or
> man_made=storage_tank), taps, wells (man_made=water_well), springs, etc.
>
> Other Concerns:
> * Based on the photos and the proximity of the points to each other, there
> seem to be multiple points representing the same infrastructure in some
> cases,
> * Some points are located inside buildings, but the photos show that they
> are outside.  You should adjust either the building or the water point
> during the import.
> * The file has 569 features.  Given the possible duplicates, and the
> points located inside buildings, both of which should be reviewed, this is
> probably too many for a single upload, and should be split into multiple
> files.
> * It seems that in some cases where there is a tank that presumably feeds
> a tap, they have been collected separately. e.g.
> https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2F8b086aee-1d4f-4270-9694-b723b0d48cf8%2F1652865747702.jpg,
> and
> https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2Fe662dbd4-6604-4f4b-8b3f-5b596cd67925%2F1652866359311.jpg
>
> Mike
>
> [0] https://wiki.openstreetmap.org/wiki/Key:operator:type
>
> On Tue, Nov 8, 2022 at 10:17 PM Stellamaris Nakacwa <sn00013 at mix.wvu.edu>
> wrote:
>
>> Dear Phil,
>> Data is going through the cleaning process in JOSM at the moment.
>> Pump =yes (for both manual and powered). Pump = no f(or no pump
>> application at all).  Some tanks do have pumping systems while others have
>> gutters.
>>
>> fee = yes (people pay to access water) Every water system establish
>> involves payment for establishment whether paid by individuals or the
>> government.
>>
>> Stellamaris
>>
>>
>> On Wed, Nov 9, 2022 at 12:08 AM Phil Wyatt <phil at wyatt-family.com> wrote:
>>
>>> Hi Stellamaris,
>>>
>>>
>>>
>>> I continue to have some concerns on the data and tagging, especially
>>> when looking at the associated photos.
>>>
>>>
>>>
>>> Things such as
>>>
>>>
>>>
>>>    - protected_spring with pump=yes but no sign of any pump in the
>>>    associated image?
>>>       -
>>>       https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2F50ab737f-83b3-4441-95fd-f9f5ff4a6270%2F1653126241419.jpg
>>>    - Type=tap, pump=yes, fee=yes but the image looks to be an elevated
>>>    water tank/tower?
>>>       -
>>>       https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2F31ea584e-cbb1-4b71-97a6-43308cd1480a%2F1652871763352.jpg
>>>    - I am struggling to understand the pump tagging when many don’t
>>>    seem to have a pump at all and the usual pump tagging would be one of
>>>    powered/manual/no
>>>       - https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_well
>>>
>>>
>>>
>>>    - Does fee=yes mean that a payment is made for delivery of water to
>>>    the site (ie piped from somewhere else or via infrastructure from others)
>>>    or is it that an end user pays for the water when obtained from the tap?
>>>
>>>
>>>
>>> Cheers - Phil
>>>
>>>
>>>
>>> *From:* Stellamaris Nakacwa <sn00013 at mix.wvu.edu>
>>> *Sent:* Wednesday, 9 November 2022 12:11 PM
>>> *To:* Mike Thompson <miketho16 at gmail.com>
>>> *Cc:* Imports OpenStreetMap.org <imports at openstreetmap.org>
>>> *Subject:* Re: [Imports] UPLOADING U-WIMP project data to osm
>>>
>>>
>>>
>>> I have put the files into this public repository
>>> <https://github.com/StellaWava/U-WIMP-OSM-DATA> and everyone should be
>>> able to access them.
>>>
>>>
>>>
>>> I have already created an import-specific osm username as directed by
>>> the imports wiki and I am going to follow what you and  @*Andy
>>> Townsend *have suggested testing my upload.
>>>
>>> Hope to return with a success alert!
>>>
>>>
>>>
>>> Thank you all!
>>>
>>>
>>>
>>> Best,
>>>
>>> Stellamaris
>>>
>>>
>>>
>>> On Mon, Nov 7, 2022 at 6:18 PM Mike Thompson <miketho16 at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Nov 7, 2022 at 2:44 PM Stellamaris Nakacwa <sn00013 at mix.wvu.edu>
>>> wrote:
>>>
>>>  am not sure I can write an import/upload process before successfully
>>> uploading the data
>>>
>>> The whole point is to write the process instructions *before* you start
>>> the import/upload so the OSM community can review and provide feedback.  I
>>> don't think these instructions have to be super complicated, and if you
>>> learn something during the process you can augment them later with "lessons
>>> learned"
>>>
>>>
>>>
>>> I will make sure that in the guide, I emphasize that for the new mappers
>>> as more, I am just going to simply edit my .csv and then reconvert it to a
>>> geojson.
>>>
>>> Ok, you should share a link to the full .csv, and a link to the final
>>> GeoJSON file after you have made the changes.  This should be done well
>>> before the import/upload starts so that the community can review.
>>>
>>>
>>>
>>>
>>>
>>> I am following the normal JOSM edit guideline
>>> <https://toolbox.hotosm.org/pages/data-cleaning-upload-and-quality-assurance/5.1-data-cleaning-with-josm/>
>>> to perform the upload.  [Downlaod data in AOI, merge, validate, upload]
>>>
>>> My data is just water points, nothing extra. So, I do not think I have
>>> anything complicated.
>>>
>>>  You probably can either reference those guidelines in your proposal, or
>>> cut/paste from it.   I don't think your process will be exactly as shown in
>>> those guidelines, so selectively cutting and pasting will probably be
>>> best.  For one thing, you have one large file, and in the guidelines they
>>> are starting with one file per feature.
>>>
>>> Also,
>>>
>>> * I believe your file is quite large, and reviewing all of those points
>>> in one sitting in JOSM using the todo list might not be practical.  I would
>>> suggest splitting the final file into more manageable chunks.
>>>
>>> * Please make it clear in your instructions that if there is an existing
>>> well or spring in OSM, that you will preserve it, copy tags from the import
>>> data as appropriate, and delete the imported point.  You should not be
>>> creating duplicates, nor should you be deleting existing data in favor of
>>> the imported data.
>>>
>>> * Are you doing this all yourself, or will there be people helping you?
>>> It seems like a lot of data for one person to review/import.  If you are
>>> going to have multiple people, how are you going to keep track of who is
>>> doing what?  The Denver building import was set up using the tasking
>>> manager, such that when a mapper started mapping a task they automatically
>>> got both the OSM data and the import data for that location.  This does
>>> require some web accessible place to store the import data.
>>>
>>> * The import should not be done under your regular OSM account, you
>>> should create a separate account for imports (maybe you mentioned this
>>> already in your proposal and I missed it).
>>>
>>>
>>>
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20221109/c79741ed/attachment-0001.htm>


More information about the Imports mailing list