Earlier quoted context omitted.
I tend to agree with you, having done a fair bit of cursing at the OSM format as well. Yet they've made an open source map, and I haven't. The data tells me that I'm wrong.
For a crowd sourced dataset, a strict ontology anyway wouldn't work. Instead of messy tag definitions you'd have tag use that didn't align with the definitions. I don't mean that as an argument against improving the tagging! The biggest friction point is probably that people resist rationalization of tagging schemes that have demonstrated themselves to be problematic. The tagging system in the iD editor tries to addr…
In Defense of OpenStreetMap's Data Model
91–100 of 130 posts
Re: In Defense of OpenStreetMap's Data Model
#92Earlier quoted context omitted.
> The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input. Agreed. However, it might be not so easy for historical dates, because doing it correctly requires great diligence on the part of the tool developer as well as from the user to choose the correct calendar system. For example: Q: What is the correct representation of the date of Caesar's death, 15 Mar…
In Java and Javascript, months are 0-based, so October is 9. Geez, imagine forcing people to write "October 15, 2019" as "2019-09-15"
Re: In Defense of OpenStreetMap's Data Model
#93Earlier quoted context omitted.
why not use the universal date format [1] that works for everyone? yyyy mm dd mm yyyy [1] https://twitter.com/dan_abramov/status/1447710863960551433
Unix time is the real universal date format surely? It underpins basically everything in datetime database entries. The problem is that most people can't read that along with the French somehow never being able to convince the world to adopt decimal time.
maybe in space, but 2038 will have an interesting time warp.
Re: In Defense of OpenStreetMap's Data Model
#94Re: In Defense of OpenStreetMap's Data Model
#95Earlier quoted context omitted.
Why do you need to change the data format to make it faster (at the cost of making it harder to work with to end users)? The data is the same as it was at the beginning, it doesn't justify a technical redesign. Why not just create accelerators based on an intermediat format?
End users don't work with data format directly. They use tools and these tools could be better, if data format was improved.
Vespucci is a really handy Android app for making contributions to OSM, but it's hard to use without knowing something about the tagging conventions.
Re: In Defense of OpenStreetMap's Data Model
#96I’ve started playing with data from OpenStreetMap. It started with me trying to fetch all the places where I could get water when moving around Copenhagen, which turned out not to be as easy as first envisioned, because OSM seems to have a lot of different ways to categorise available water, which makes sense, OSM and the tagging system isn't there to support only my usecase, and describing my idea doesn't fit 1:1 wi…
Re: In Defense of OpenStreetMap's Data Model
#97I'm not sure I like OSMs obsession with the data model. I guess this has to do with its business model, but then let's not pretend the product manager is tasked to optimize for end-users.
I'd like it to focus on the UI. The easier it is to input a geographic thingie and the easier it is to visualize the geographic thingie, the better OSM both for users and volunteers.
Two issues to strengthen my point:
1. The osm-tag mailing list regularly discusses how tags are visualized in various renderers when recommending which to choose.
2. Quick mobile-based correction are nearly impossible with OSMAnd. I'd love to take a picture and write a quick note like "speed limit changed", so that someone (perhaps a bot) can pick this up and update the data model. Same with restaurant opening hours. Or various POIs.
Re: In Defense of OpenStreetMap's Data Model
#98> The harder you make it for them to edit, the less volunteers you’ll get. I'm not sure I like OSMs obsession with the data model . I guess this has to do with its business model, but then let's not pretend the product manager is tasked to optimize for end-users. I'd like it to focus on the UI. The easier it is to input a geographic thingie and the easier it is to visualize the geographic thingie, the better OSM both…
This can be done with StreetComplete (Android app) - long press on map to create note, photo can be added.
> Same with restaurant opening hours. Or various POIs.
You can also outright survey this with StreetComplete. See https://github.com/streetcomplete/StreetComplete
Note: speed limit needs to be enabled, it is disabled by default. It is also unavailable in USA due to horrific default speed limit system which requires massive work to support.
Disclaimer: I am one of people working on StreetComplete
> I'm not sure I like OSMs obsession with the data model.
Given effort that went into various parts - fundamental data model has not received any changes for a long time. I would not describe it as obsession.
> I guess this has to do with its business model
OSM do not really have business model, it is not a business
Re: In Defense of OpenStreetMap's Data Model
#99The only thing I'm missing is any indication that OSMF's course actually did cause any problems in reality.
Re: In Defense of OpenStreetMap's Data Model
#100Earlier quoted context omitted.
In Java and Javascript, months are 0-based, so October is 9. Geez, imagine forcing people to write "October 15, 2019" as "2019-09-15"
Yeah, as it already is an imposition to use 10 for what is called "Month Eight" (from Lat.: octo = 8).
Would it really have been too much to ask that July and August come after December?!