[Imports] UPLOADING U-WIMP project data to osm

Tue Nov 22 23:58:59 UTC 2022

Mike, we had the minimum as the developed data model in wiki. You all
cameup with additional, and all other tags and aas much as I tried to
explain the critical point of my research, it did not matter.

While the validation happened, I ensured that all thoughts from this page
were considered regardless if they were really necessary or not.

At this point, we are not removing those tags, that sounds crazy to me.

I am sorry, I am taking this stand!

Thank you!

Stellamaris.

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

> I am sorry that my findings about these data bothered you.  It wasn't
> meant to reflect on you personally.  However, the fact remains that the
> data is of poor quality.  I think I have cited more than enough examples to
> demonstrate that.  The data may have been "field verified", but that
> doesn't mean it is correct.  If you want to rebut my specific findings with
> evidence, I would be happy to read it and respond in kind.
>
> Yes, I, and others have suggested you add tags, but in some cases these
> suggestions have been misapplied. For example, it was suggested that if an
> object was on top of a building that the tag location=rooftop be added,
> somehow this became location=ontop_building.  There are also a number of
> location=ontop_tree, none of which make any sense when one examines the
> actual photo associated with the point in question, and no one on this list
> ever suggested that value.  Another misapplied suggestion is
> man_made=water_well added to things that are not wells, for example, where
> type=water_truck_tank, and the linked photo suggests it is in fact a tank.
> Someone also suggested springs be tagged as natural=spring, but in at least
> one case, one was tagged as man_made=natural.  I am pretty sure no one ever
> suggested that, and it doesn't make sense.
>
> I think Rob does have a good suggestion, just start with part of the data,
> but I would just do a single type of feature, such as water taps.  I would
> only include things that actually appear as water taps (if that is the
> specific feature you choose) in the linked image.  I would keep the tagging
> to a minimum, such as just man_made=water_tap + drinking_water=yes|no, but
> I would urge you to consult the wiki to see the current documented tags and
> come up with your own proposal.  This minimal tagging avoids the current
> inconsistencies where there are wells that deliver surface water for
> example (which I don't think makes sense).
>
>
>
> Mike
>
>
>
>
> On Tue, Nov 22, 2022 at 2:15 PM Stellamaris Nakacwa <sn00013 at mix.wvu.edu>
> wrote:
>
>> 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/2619738d/attachment-0001.htm>