Live data from Hacker News

In Defense of OpenStreetMap's Data Model

stevecoast.substack.com

91–100 of 130 posts

Re: In Defense of OpenStreetMap's Data Model

#91

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…

Maybe there's a need for bridging app. Something to aid,suggest,review. So people could spend their energy slowly but surely ? an OSMCAD

Re: In Defense of OpenStreetMap's Data Model

#92

Earlier 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"

Yeah, as it already is an imposition to use 10 for what is called "Month Eight" (from Lat.: octo = 8).

Re: In Defense of OpenStreetMap's Data Model

#93
post #35

Earlier 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.

> Unix time is the real universal date format surely?

maybe in space, but 2038 will have an interesting time warp.

Re: In Defense of OpenStreetMap's Data Model

#95

Earlier 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.

Some of us do, though.

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

#96
post #11

I’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…

You missed (at least) one: https://wiki.openstreetmap.org/wiki/Tag:man_made%3Ddrinking_...

Re: In Defense of OpenStreetMap's Data Model

#97
> 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 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…

> I'd love to take a picture and write a quick note like "speed limit changed"

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

#99
The author is ranting a lot about OSMF's recent decisions, gives all kinds of reasons why they will undoubtedly lead to horrible consequences and grants sage advice what should have been done instead.

The 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

#100

Earlier 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).

Glad to hear I'm not the only one. A switch flipped in my brain once I realized this and now I routinely mix up October and August.

Would it really have been too much to ask that July and August come after December?!

Post reply on HN