In Defense of OpenStreetMap's Data Model • Hacker News Board

Re: In Defense of OpenStreetMap's Data Model

#31

Post by atoav » Mon, Jun 06, 2022, 12:37 PM UTC

zigzag312 wrote: post #24

Author states: >And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life. While too much rules and complexity can certainly be bad, some basic amount of standardi…

The date example is a good one. No one has fun by choosing their own date format. This is putting the burden of choice onto the user. They might like to think about some map stuff and now they have to think about data format stuff.

Of course projects like these have to strike a balance between the strictest bureaucratic nightmare and such a structure so loose that people are overburdened by the available options at every corner.

I think a lot of that complexity can (and should!) live in the tools themselves. Who cares about a date format, when the tool that creates it offers a date picker or extracts the correct date from the meta data of an image? The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.

Re: In Defense of OpenStreetMap's Data Model

#32

Post by zigzag312 » Mon, Jun 06, 2022, 12:37 PM UTC

TuringTest wrote: post #22

maxerickson wrote: post #19

Earlier quoted context omitted.

The "expression" layer of the data model has had 20 years to evolve and has largely been static for a decade. Making everything slower and harder to retain flexibility you don't need isn't a great tradeoff.

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.

Re: In Defense of OpenStreetMap's Data Model

#33

Post by matkoniecz » Mon, Jun 06, 2022, 12:37 PM UTC

> Let us pray that the EWG is just throwing Jochen a bone to go play in the corner and stop annoying the grownups.

That is neither helpful, not useful, nor making me more likely to treat this diatribe more seriously.

Re: In Defense of OpenStreetMap's Data Model

#34

Post by francisofascii » Mon, Jun 06, 2022, 12:38 PM UTC

Aachen wrote: post #17

kawsper wrote: 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…

I don't understand how this doesn't fit your use case. The tags are for different things, e.g. > for places where you can get larger amounts of "drinking water" for filling a fresh water holding tank, such as found on caravans, RVs and boats versus > a man-made construction providing access to water, supplied by centralized water distribution system (unlike in case of man_made=water_well [...]). The tag man_made=wate…

When features are sometimes tagged specifically and other times tagged more generically, it is impossible to get valid results. You either have to filter on the more specific tag (leaving out valid features) or include the generic tagged features (including features that should not be).

Re: In Defense of OpenStreetMap's Data Model

#35

Post by joshxyz » Mon, Jun 06, 2022, 12:41 PM UTC

zigzag312 wrote: post #24

Author states: >And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life. While too much rules and complexity can certainly be bad, some basic amount of standardi…

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

Re: In Defense of OpenStreetMap's Data Model

#36

Post by matkoniecz » Mon, Jun 06, 2022, 12:46 PM UTC

TuringTest wrote: post #29

purple_turtle wrote: post #25

Earlier quoted context omitted.

> Having a file format that won't admit that temporary state means that either the user can't save incomplete draft work, or that an entirely different format will be needed to represent such in-process work. Saving such temporary state is very rarely needed in OSM and should be never uploaded to the OSM database. In addition, in almost all cases it can be simply saved as area of shape that is not yet matching intend…

> Saving such temporary state is very rarely needed in OSM and should be never uploaded to the OSM database. Maybe, but you're missing the other use case - that in the future you'll need an extension requiring geometries that are considered invalid by the current set of rules, forcing you to update all tools processing the file format to acommodate the new extension. Keeping storage and validation as two separate ste…

I think that noone serious proposes to include rules like

> You could have rules that say you can’t link Finland to Barbados.

in the data model. That is a red herring.

But rules like "area must be a valid area" are a good idea, in the same way as Wikipedia is requiring article code to be a text and is not allowing saving binary data there.

Re: In Defense of OpenStreetMap's Data Model

#37

Post by matkoniecz » Mon, Jun 06, 2022, 12:48 PM UTC

TuringTest wrote: post #22

maxerickson wrote: post #19

Earlier quoted context omitted.

The "expression" layer of the data model has had 20 years to evolve and has largely been static for a decade. Making everything slower and harder to retain flexibility you don't need isn't a great tradeoff.

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?

It is plausible that data format can be made better for everyone at cost of very significant redesign cost of software interacting with it.

> Why not just create accelerators based on an intermediat format?

making things easier for mappers by introducing new data format requires changing format used by mappers

Re: In Defense of OpenStreetMap's Data Model

#38

Post by uptime » Mon, Jun 06, 2022, 12:53 PM UTC

I have been looking into improving kerb and traffic_signals data for some bboxen. It is daunting, and I figure I need to work backwards - try to find out what the accessibility map apps look for and use those pairs. If I know what target I am shooting for I guess it will be alright. This is like my first week looking into this and I hope to find these targets soon.

Re: In Defense of OpenStreetMap's Data Model

#39

Post by RcouF1uZ4gsC » Mon, Jun 06, 2022, 12:56 PM UTC

joshxyz wrote: post #35

zigzag312 wrote: post #24

Author states: >And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life. While too much rules and complexity can certainly be bad, some basic amount of standardi…

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

It actually doesn't work for Americans who write:

mm dd yyyy

Re: In Defense of OpenStreetMap's Data Model

#40

Post by speed_spread » Mon, Jun 06, 2022, 12:57 PM UTC

TuringTest wrote: post #22

maxerickson wrote: post #19

Earlier quoted context omitted.

The "expression" layer of the data model has had 20 years to evolve and has largely been static for a decade. Making everything slower and harder to retain flexibility you don't need isn't a great tradeoff.

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?

Properly normalized data isn't just faster, it's also easier to work with for the end user. There are much less exceptions, edge cases and snafus to work around and test for. If you're talking about the transition period between formats, well yeah, you're gonna see things breaking. But these were already broken, just not in apparent ways. In the end, everybody wins.