[Imports] UPLOADING U-WIMP project data to osm

Stellamaris Nakacwa sn00013 at mix.wvu.edu
Tue Nov 22 21:15:07 UTC 2022


I am sorry about what regards logical and illogical but I am not changing
things that were picked from field. That can only be changed with field
verification. And, yes, it possible that data collector established
existence of both kinds of harvested water.

The pump:system does not exit in osm. It us a new tag. People that
collected this data have validated their data and unfortunately I am not
going into it to re-engineer it based on what feels and what doesn't.

No! You did not mention the operator aspect and also we are very fine by
the 3 combinations because that is all that matters to the community.

I am sorry but the data is pretty correct as it is. Unless, it is your wish
to do the field data correction, I am happy to surrender the project to
you'all. Otherwise, there is no legitimate reason why it should not be
uploaded.

Really sorry, it bothered me.

Stellamaris



On Tue, Nov 22, 2022, 3:30 PM Mike Thompson <miketho16 at gmail.com> wrote:

> Hello Stellamaris,
>
> Ok, I look forward to seeing the full dataset.  In the meantime, here is
> some additional feedback:
>
> In the current .osm file there are 6 cases where
> type=rainwater_harvest_tank where pump:system=combined.   Based on the
> other features, I presume that "combined" means groundwater and surface
> water.  It seems illogical that a rainwater collection system would involve
> groundwater.
>
> There are 9 total features, including the 6 above, where there is a
> pump:system=* tag, according to taginfo [1] there are no occurrences of
> this tag presently in OSM.  A better tag might be water_source=* [2], but
> we should get some additional OSM community input on this.
>
> Regarding pump:system=combined. Does this mean surface water and
> groundwater?  Perhaps use surfacewater;groundwater (a semicolon separated
> list)
>
> Speaking of surfacewater, according to taginfo, this doesn't appear at all
> in the OSM database presently.  However, surface_water does appear a few
> times.
>
> I think I mentioned this before, but the operator=* tag is for the
> specific name of the operator, such as " City of Greeley" or "ABC
> Company."  Using operator:type=* [3] might be better when you only know the
> type of operator (private, institution, etc.)
>
> This latest version of the dataset introduces a tag that wasn't present in
> the earlier version, use=*  with values such as service,distribution,
> residential.  This tag currently doesn't appear in the OSM database.  It is
> not clear what the meaning of this tag is. I suspect that the same
> information could be represented with existing and well accepted tags.
>
> The feature at 2.7905419, 32.3458487 is a water tank based on its photo
> and is tagged as such).  The tank system itself does not appear to be
> designed to dispense water directly based on its photo, therefore it should
> not be tagged as amenity=water_point. However, the feature at 2.7905271,
> 32.3459179 seems to provide the mechanism by which water is dispensed from
> the tank, and in fact it (the tap at 2.7905271, 32.3459179) appears in the
> photo of the tank (lower right corner).  For reference here is the link to
> the photo of the tap at 2.7905271, 32.3459179 [5].  It is also interesting
> to note that the tank is tagged pump=yes, but there is no handle for a
> manual pump, nor wires for an electric pump (nor solar panels for an
> electrical pump).  It is probably gravity fed.  The tap at 2.7905271,
> 32.3459179 is also tagged as pump=yes (but is probably gravity fed from the
> tank). Interestingly one is tagged pump:system=groundwater, and the other
> is tagged pump:system=surfacewater.
>
> The feature at 2.8026878, 32.348049 is tagged as man_made=water_well, but
> type=rainwater_harvest_tank.  It is also tagged as location=ontop_building,
> but its photo[ 6] clearly shows that it is on the ground.
>
> Speaking of location=ontop_building, currently this doesn't appear in the
> OSM database[7], the tag that Martin recommended was location=rooftop,
> which appears in the OSM data 3,606 times
>
> The feature at 2.8075865, 32.3426397 is another one that has been tagged
> location=ontop_building, but where its photo[8] clearly shows it is on the
> ground. It is also tagged as pump=yes, yet there are no wires for an
> electrical pump, nor handle for a manual pump.  Finally, it is tagged as
> man_made=water_well, yet there is no evidence of a well in the photo.
>
> There are many, many more issues with these data!  Almost every query I
> run reveals another problem.
>
> In general:
> * These data appear to be internally inconsistent
> * Some issues that have been pointed out before have not been addressed
> * Some issues that have been previously addressed have reappeared in the
> data
> * Entirely new issues have been introduced
>
> Given the huge number of issues, my recommendation is that this import not
> take place.
>
> Mike
>
>
>
> [1] https://taginfo.openstreetmap.org/search?q=pump%3Asystem
> [2] https://taginfo.openstreetmap.org/search?q=water_source
> [3] https://wiki.openstreetmap.org/wiki/Key:operator:type
> [4]
> https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2F0618b2f3-bd6c-4895-bc17-8555b0070ea2%2F1652865529219.jpg
> [5]
> https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2F35efde5e-809d-4b26-9706-669d1826bfb1%2F1652865333125.jpg
> [6]
> https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2F9ce3cdda-eb9e-4d80-bc5f-178b654fe84f%2F1652961427984.jpg
> [7] https://taginfo.openstreetmap.org/search?q=%22ontop_building%22#values
> [8]
> https://kc.humanitarianresponse.info/media/original?media_file=wava_stella%2Fattachments%2Fb5a9b6358d8141adabcb9d5c4f0dd560%2Fe7e0a4bc-37cc-40fc-b124-d37eca587560%2F1652875927591.jpg
>
>
>
>
>
>
> On Tue, Nov 22, 2022 at 10:49 AM Stellamaris Nakacwa <sn00013 at mix.wvu.edu>
> wrote:
>
>> Sure! I will be attaching them as they come in per dates. However, you
>> can use the sample to tease out all thoughts.
>>
>> Thank you!
>>
>> Stellamaris
>>
>> On Tue, Nov 22, 2022, 11:15 AM Mike Thompson <miketho16 at gmail.com> wrote:
>>
>>> Hello Stellamaris,
>>>
>>> The community needs to have access to all of the data in the format that
>>> you intend to import so that we can review it, especially given the issues
>>> so far with this dataset.
>>>
>>> BTW, there is no GeoJSON file in the repository[0] that I am seeing,
>>> only the .csv and the .osm file.
>>>
>>> Mike
>>>
>>> [0] https://github.com/StellaWava/U-WIMP-OSM-DATA
>>>
>>> On Tue, Nov 22, 2022 at 8:53 AM Stellamaris Nakacwa <sn00013 at mix.wvu.edu>
>>> wrote:
>>>
>>>> Oh! Sorry Mike,
>>>>
>>>> The csv is the initial dataset. The .geojson is the well validated
>>>> dataset sample.
>>>>
>>>> Stellamaris
>>>>
>>>>
>>>> On Tue, Nov 22, 2022, 10:45 AM Mike Thompson <miketho16 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Stellamaris,
>>>>>
>>>>> Thanks, I downloaded the current data.
>>>>>
>>>>> Some initial thoughts:
>>>>> * The CSV file has 570 points but the OSM file only has 93, why?
>>>>> * The OSM file contains a county=* tag.  As OSM is a spatial database,
>>>>> it is not necessary to indicate the county in which a feature is within.
>>>>> * Nevertheless, if for some reason you need to include the county in
>>>>> the data (you will need a strong case for doing this), you should probably
>>>>> put the value in title case. Currently all points are tagged as county=aswa
>>>>> * The OSM file contains tags for latitude and longitude, as a spatial
>>>>> database, this is not necessary and is redundant.  These should be removed.
>>>>>
>>>>> In general, while there have been some good changes to the data, there
>>>>> have also been some changes that have made the data worse (I don't recall
>>>>> latitude and longitude being in the previous data).
>>>>>
>>>>> I will try to get some more time to review later, I have noticed some
>>>>> other strange things about this data, but need to research further.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>> On Tue, Nov 22, 2022 at 8:21 AM Stellamaris Nakacwa <
>>>>> sn00013 at mix.wvu.edu> wrote:
>>>>>
>>>>>> Hello Mike,
>>>>>> The link to the data is within the document... Under current status.
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Stellamaris
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 22, 2022, 10:08 AM Mike Thompson <miketho16 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Sellamaris,
>>>>>>>
>>>>>>> Thanks for providing us with the link to the documentation.  Have
>>>>>>> you made the corrections to the data that were previously suggested?  Can
>>>>>>> we have access to the corrected data?
>>>>>>>
>>>>>>> First thought on the documentation is that you need to be more
>>>>>>> specific.  For example, while doing the import, are you going to be
>>>>>>> reviewing it against existing OSM data? If the point being imported is on
>>>>>>> top of a building in the data, but the associated photo indicates that it
>>>>>>> is not in fact on top of a building are you going to adjust the location of
>>>>>>> the building, the point, or are you not going to make an adjustment?
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> On Mon, Nov 21, 2022 at 7:02 PM Stellamaris Nakacwa <
>>>>>>> sn00013 at mix.wvu.edu> wrote:
>>>>>>>
>>>>>>>> Safe Greetings All,
>>>>>>>>
>>>>>>>> Here is the documentation
>>>>>>>> <https://wiki.openstreetmap.org/wiki/Imports_Uganda_Water_Infrastructure_Mapping_Project#Current_Status>
>>>>>>>> for the U-WIMP import.
>>>>>>>>
>>>>>>>> Thank you!
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Stellamaris
>>>>>>>>
>>>>>>>> On Thu, Nov 10, 2022 at 12:19 PM Stellamaris Nakacwa <
>>>>>>>> sn00013 at mix.wvu.edu> wrote:
>>>>>>>>
>>>>>>>>> Thank you!  I will refer the latter to the first thread of this
>>>>>>>>> conversation.
>>>>>>>>>
>>>>>>>>> Stellamaris
>>>>>>>>>
>>>>>>>>> On Wed, Nov 9, 2022 at 6:59 PM Martin Koppenhoefer <
>>>>>>>>> dieterdreist at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sent from a phone
>>>>>>>>>>
>>>>>>>>>> > On 10 Nov 2022, at 00:36, Mike Thompson <miketho16 at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> >
>>>>>>>>>> > If they are truly on top of the building in reality, then they
>>>>>>>>>> should be on top of the buildings on the map, however, the ones I saw were
>>>>>>>>>> not on top of the buildings in reality (based upon the photos that the data
>>>>>>>>>> linked to)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> for features on buildings it is helpful to add location=rooftop
>>>>>>>>>> as well
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> Imports mailing list
>>>>>>>> Imports at openstreetmap.org
>>>>>>>> https://lists.openstreetmap.org/listinfo/imports
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20221122/fd7bfb54/attachment-0001.htm>


More information about the Imports mailing list