[HOT] Database, OSM & HOT (Was: Request for information about common set of tags for HOT)

althio althio.forum at gmail.com
Wed May 20 15:32:41 UTC 2015


Sorry for the partial answer and I don't mean to be harsh because I
know things around here are not easy to find and understand. We all
need pointers and FAQ or homepages and portals...

My point is... I do think that you are somehow confused between
OpenStreetMap and HOT:

OSM aka OpenStreetMap, the project, its database, its goals, its community
   - [http://www.openstreetmap.org/welcome] OpenStreetMap, the free
and editable map of the world
   - [http://www.openstreetmap.org/about] OpenStreetMap is built by a
community of mappers that contribute and maintain data about roads,
trails, caf├ęs, railway stations, and much more (note: also video
games, hairdresser, gymnastics, karate and volleyball...) (note2: also
boundaries, hospitals, schools), all over the world.

see also OSM Foundation, the entity to support the project
   - http://wiki.osmfoundation.org/wiki/Main_Page

HOT aka Humanitarian OSM Team is using a subset of OSM database and
building on it, its own goals (some overlap with OSM), its own
community (some overlap with OSM)
   - [http://hotosm.org/] The Humanitarian OpenStreetMap Team [HOT]
applies the principles of open source and open data sharing for
humanitarian response and economic development.
   - [http://hotosm.org/about]
   - [https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team]


Back to OSM and "tag soup" database. This is a rather hard and
technical topic, and not really related to HOT and this list. You will
not find the answer here, nor the most interested or skilled people.
HOT uses and contributes to the database, HOT does not control it.

A few more words anyway? ("I am not a lawyer" and "I am not a database expert").
OSM database is open, free, public, iterative and rather rich.
OSM database is not fixed, not complete, not comprehensive, not
homogeneous (spatially at least).
The philosophy and structure have their own advantages and
disadvantages compared to existing datasets.
Please appreciate the uniqueness, value and potential of OSM database
before you try to make it a clone of something existing.

All the best,

 - althio

On 19 May 2015 at 21:38, Springfield Harrison <stellargps at gmail.com> wrote:
> Hello Stefan & Blake,
> I concur with the comments about the "tag soup" mess.  As I have mentioned
> before, I am new to this OSM environment but have some years experience with
> GPS and GIS mapping and database design.
> To be honest, I was appalled when I discovered that the OSM database design
> looked like a glorified scratchpad.  I just downloaded and inspected 366,017
> OSM database records.  There were 18 Key Terms and scores of values.  I
> extracted the unique combinations of keys/values and ended up with 388
> records of those.
> It is difficult to describe the results in detail as patterns are very hard
> to see with this system.  Suffice it to say, there is an abundance of
> overlap, redundancy, ambiguity and a confusing intermingling of features and
> attributes.  Using traditional methods of querying a database, it would be
> impossible to definitively extract a meaningful subset of any of the 366,000
> records.  Generally speaking, the problem is that one feature may be
> described in many different ways that are not consistent.
> Having said all that, since I frequently hear how well all this mapping
> information is received in the field, I must conclude that this mishmash of
> tagging somehow creates a usable end product.  It may well be that I am not
> aware of magic techniques that bring order to all this chaotic tagging.
> However, if it works, it is good.  However I do believe that it will work
> better with a more robust database.
> Sorry to offer this harsh critique, but in decades of looking at database
> structures for both geographical and administrative applications, I have
> never seen such a jumble of terminology.
> Anyway, I have put together what I believe is a more appropriate Data
> Dictionary that generally parallels the best practices in database design.
> I have found this approach to be very useful, and also useful in the field,
> since being introduced to it by Trimble Navigation in the early 90s.
> I am impressed with the enthusiasm that permeates the crowd GIS initiative
> but concerned that the geographical and database underpinnings may be less
> than ideal.  My observation from creating a few software applications, is
> that the lesser trained are the users, the much greater investment there
> needs to be in the user interface and training.  GIS and GPS data collection
> is not particularly intuitive.
> My approach in projects of this kind is always to start at the far end with
> the users - what information are they wanting for whatever it is that they
> do?  Then I look at the reporting requirements and finally design the data
> collection process to feed into that.
> In the case of this emergency relief operation, I'm hard-pressed to see the
> value in mapping video games, hairdresser, gymnastics, karate and
> volleyball.  To be fair, many of the other attributes could have value in
> providing relief services but in the record set that I downloaded, there
> seems to be little information related to the emergency relief effort.  In
> over 366,000 records there are only 19 marked as aeroway = helipad.
> I'm not sure just how thorough you intend to be with the "updating,
> streamlining and regularizing" but I would be happy to help where possible.
> It would probably not be overly difficult to substitute a new
> feature/attribute catalogue into the OSM database.  Translating the existing
> mass of keys and values to their new equivalent might be more challenging.
> Databases succeed because they conform to standard pattern sets.
> Again, sorry to be less than enthusiastic but perhaps things can be
> improved.
>         Thanks for your patience, Cheers . . . . . . . . Spring Harrison

More information about the HOT mailing list