Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of OpenStreetMap's Data Model

stevecoast.substack.com

Post reply on HN
Print view View original

61–70 of 130 posts

Re: In Defense of OpenStreetMap's Data Model

#61

Post by uptime »

matkoniecz wrote: post #41
uptime wrote: post #38

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.

What exactly you are trying to do? Import data? Map something manually on your own? Something else?

Add keys to existing nodes mostly. Possibly using tasks.openstreetmap.org and/or possibly doing something in a batch if I can get data from the city to use. These structures seem well defined, thankfully. And the crossings and signal locations look to be complete.

Re: In Defense of OpenStreetMap's Data Model

#62

Post by Archelaos »

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…

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

I think the way to go is to define several layers of correctness. A data set might then be partially valid. In such cases a tool might, for example, support transitions from a complete valid state A to a complete valid state C by an intermediate partially valid state B. (As databases with referential integrity may allow intermediate states in a transaction where referential integrity is broken.)

Re: In Defense of OpenStreetMap's Data Model

#63

Post by maxerickson »

tinus_hn wrote: post #12

What is stopping users who have a problem with the model from transforming the data into a form that is better for their use case?

That's mostly what people do.

The current format stores locations and references to locations, so for example, a line feature only stores references to locations, so to realize it on a map, you have to go through the data and find all the locations it references and build up the actual geometric feature. So people do caching and so on, for sure.

The proposed changes would make that sort of data transformation easier and less resource intensive.

Re: In Defense of OpenStreetMap's Data Model

#64

Post by pramsey »

matkoniecz wrote: post #28

> The harder you make it for them to edit, the less volunteers you’ll get. And that is why dedicated area type (rather than representing areas with lines or special relations[0]) could help new mappers and new users of data. There would be very significant transition costs, but maybe it would be overall beneficial. It is possible to have objects that are both area and line at once. Or area according to one tool/map/e…

1000 times yes! I am a spatial data expert but only a some-time OSM editor and I still have yet to figure out how to create a polygonal feature more complex than a single building footprint. The theoretical advantage of a unified topology model of just nodes/edges where polygons and lines share core geometry is nullified by cultural rules that say "don't do that" to editors (I had a bunch of parks that shared a boundary with a road reverted with nasty notes). The current setup is not just hard for processors, it's hard for non-experts to understand and therefore a higher barrier than a simple polygon model would be.

Re: In Defense of OpenStreetMap's Data Model

#65

Post by pramsey »

Doctor_Fegg wrote: post #50
TuringTest wrote: post #23

Earlier quoted context omitted.

> Both have been hugely successful, and both have the same pile of downsides. Exactly. And the solution should not be to throw away spreadsheets completely and turn them into relational databases, but to create new tools to alleviate the downsides and reduce their impact (possible by exporting the spreadsheet information into a relational database, but without taking away the user's option to continue working with it…

No one is suggesting throwing away OSM's data model completely. The current suggestion is basically "maybe we should think about a point release to properly address an ugly hack we invented in 2007".

Right? The emotion of the response seems completely out of scale to the ambition of the reform proposed. "Maybe polygons?"

Re: In Defense of OpenStreetMap's Data Model

#66

Post by NelsonMinar »

matkoniecz wrote: post #33

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

It is the kind of disrespectful rhetoric that defines the OSM community though.

Re: In Defense of OpenStreetMap's Data Model

#67

Post by Aachen »

francisofascii wrote: post #47
matkoniecz wrote: post #42

Earlier quoted context omitted.

In this case it should not be a problem - listing mapped places suitable to get drinking water is quite reasonable here.

Not really. Sometimes you specifically want a water fountain where the water shoots upwards. Not a faucet.

If only we paid people to map everything to the detail you specifically need. I've never seen a public faucet that does what you describe, only in American movies in high schools (so those aren't public and most mappers won't know they're there or, even if, you wouldn't be allowed to use it as a non-student). I'm not sure the tagging scheme is the problem here: even if you'd enforce using the right tag by giving everyone mandatory training and exams so they tag everything perfectly, you'd not get this sort of detail necessarily, at least not without doubling the number of contributors as compared to today. (And that's from a German/Dutch perspective, countries which are already pretty well-mapped. In Belgium you probably need to quadruple the force or more.)

Re: In Defense of OpenStreetMap's Data Model

#68

Post by ciphol »

seoaeu wrote: post #60

The claim that a dataset with billions of users has only dozens of people able/interested in doing data processing on it is a damning admission that the format is too hard to deal with

Dozens of open source volunteers who are interested in volunteering their free time to do software development using the format.

In addition to the innumerable developers in Facebook, Apple, and other corporations who are paid to do the data processing and actually bring the data to those billions of users.

Re: In Defense of OpenStreetMap's Data Model

#69

Post by shagie »

Grimburger wrote: post #46
joshxyz wrote: 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.

As much as it is maligned, base 60 is rather convenient. It's easy to take 1/2, 1/3, 1/4, 1/5 and 1/6th of that number. Base 12 has this property too (though lacks the easy 1/5th).

Re: In Defense of OpenStreetMap's Data Model

#70

Post by matkoniecz »

francisofascii wrote: post #47
matkoniecz wrote: post #42

Earlier quoted context omitted.

In this case it should not be a problem - listing mapped places suitable to get drinking water is quite reasonable here.

Not really. Sometimes you specifically want a water fountain where the water shoots upwards. Not a faucet.

then exclude `man_made=water_tap`

in this case extreme fragmentation of tagging is actually useful

Post reply on HN