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

101–110 of 130 posts

Re: In Defense of OpenStreetMap's Data Model

#101

Post by xg15 »

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.

As someone else in this subtree mentioned, apparently this flexibility wasn't needed for the last 20 years.

Re: In Defense of OpenStreetMap's Data Model

#102

Post by xg15 »

TuringTest wrote: post #7
MontyCarloHall wrote: post #5

Earlier quoted context omitted.

The entire article can be summed up as: “OSM stores maps as graphs, in flat files where each line is either a node, an ordered list of nodes, or metadata. The graph nodes can be arbitrarily ordered in OSM files, which leads to computational complexity when parsing them. This is not a bad thing, since it means that the spec for OSM files can be extremely simple, which makes it easy for people to contribute to OSM. Oth…

> OSM stores maps as graphs, in flat files where each line is either a node, an ordered list of nodes, or metadata. The graph nodes can be arbitrarily ordered in OSM files, which leads to computational complexity when parsing them. This is not a bad thing, since it means that the spec for OSM files can be extremely simple, which makes it easy for people to contribute to OSM. That's actually a sensible design. Treat u…

> Treat user-facing stored data as user interface.

Are you telling me, the main mode of contributing to OSM should be to edit XML files and put in GPS coordinates by hand?

That would be about the most user-hostile UI for map editing I could think of.

Re: In Defense of OpenStreetMap's Data Model

#103

Post by uptime »

matkoniecz wrote: post #71
uptime wrote: post #61

Earlier quoted context omitted.

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.

In this case I would strongly encourage to start from manual mapping. StreetComplete Android app may be useful here (disclaimer: I am involved in making it). See also https://wiki.openstreetmap.org/wiki/Import/Guidelines before importing data

Thank you!

Re: In Defense of OpenStreetMap's Data Model

#104

Post by Archelaos »

BitwiseFool wrote: post #100
Archelaos wrote: post #92

Earlier quoted context omitted.

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?!

  Q: Why do software engineers confuse Halloween and Christmas?
  A: Because Oct. 31 = Dec. 25

Re: In Defense of OpenStreetMap's Data Model

#105

Post by jasonwatkinspdx »

RicoElectrico wrote: post #8

The proposed improvements would obsolete a bunch of problems such as broken polygons [1] which happen regularly. They would also make processing OSM more accessible without needing to randomly seek over GBs of node locations just to assemble geometries which takes a significant runtime percentage of osm2pgsql. For me Steve Coast lost his credibility when he joined the closed and proprietary what3words. [1] https://wi…

What 3 Words makes me so angry.

There's around 5.1e14 meters squared on the surface of earth. It takes 34 bits to address this uniquely. If we use one of EFF's dice words style short word lists (6^4 words), we need 5 words to describe any point on earth with 1 meter precision.

If we use a projection like say S2 (though plenty of other options exist), these 5 word locators will show strong hierarchical locality. In any specific area for example, there's likely only 3 distinct top level words. Likewise, the last word is useful but probably unnecessary precision for "find the building" day to day use. So the middle 3 words will be sufficient to be unambiguous in most cases, and if people used this system they'll naturally become familiar with the phrases typical to their locale.

All of this can be done with an algorithm a freshman cs student can understand, with a trivial amount of reference data. It can run on any mobile device made in the last 15 years without an internet connection.

I designed a scheme like this for fun years ago, just because it was a natural outflow of some stuff I was doing with dicewords for default credentials in a consulting context, and I just find spatial subdivision structures neat.

It's hard to interpret what3word's scheme as anything but craven rent seeking. They want to keep the mapping obscure, and fundamentally sacrifice usability in the interests of this. That what3words markets this specifically as a solution for low income nations, and dupes NGOs that are not tech savvy in the service of this is utterly #$%@$#ing revolting.

Imagine trying to rent seek on selling poor people their own street addresses, if you'll let me be slightly hyperbolic.

There is no reason a scheme like this can't simply be a standard from some appropriate body, and a few open source reference implementations.

Re: In Defense of OpenStreetMap's Data Model

#106

Post by extropy »

m463 wrote: post #93
Grimburger wrote: post #46

Earlier quoted context omitted.

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.

Only for the ones trying to write it down as 32 bit signed int.

Nothing wrong with the format itself.

Re: In Defense of OpenStreetMap's Data Model

#107

Post by snickerer »

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 spent 20 months of my life traveling around Europe and Asia and I found the sources to fill up my camper's water tank mostly using OSM data! It works very well in most areas.

I used the the app Maps.me for that (which by the way I would not recommend anymore). Maps.me's internal search function is not intuitive but I found out the right key words to get to drinking water sources.

To your list I would add the search for springs. Especially in mountainous areas you often find usable springs (sometimes pipes coming out of a wall) with drinking water.

Re: In Defense of OpenStreetMap's Data Model

#108

Post by matkoniecz »

snickerer wrote: post #107
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 spent 20 months of my life traveling around Europe and Asia and I found the sources to fill up my camper's water tank mostly using OSM data! It works very well in most areas. I used the the app Maps.me for that (which by the way I would not recommend anymore). Maps.me's internal search function is not intuitive but I found out the right key words to get to drinking water sources. To your list I would add the search…

> I used the the app Maps.me for that (which by the way I would not recommend anymore).

Organic Maps is its successor - https://organicmaps.app/

Re: In Defense of OpenStreetMap's Data Model

#109

Post by pbronez »

Grimburger wrote: post #82
lovemenot wrote: post #55

Earlier quoted context omitted.

Why make a good point and follow it with a bad joke which: both has a class of victim and does not work as a joke? Nobody has ever heard of "the French" undertaking such a project. And if it had ever happened, it would most surely have been a particular Academy or the like. Not the 65M people under your careless swipe.

I'm actually one of those weird folks who likes decimal time and maybe one day we'll get there given that every other metric system was adopted by engineers worldwide except for time. Wasn't meant as some slight against the French, completely the opposite hey, honestly think they had the right idea, the rest of the world got it wrong...and... that's very much a minority opinion these days. Some things are just ingrai…

French Revolution came up with some wild shit and some truly excellent ideas. That’s a season of change for ya… high variance.
Post reply on HN