Live data from Hacker News

OpenStreetMap Is in Trouble

blog.emacsen.net

281–290 of 290 posts

Re: OpenStreetMap Is in Trouble

#281
post #277

Earlier quoted context omitted.

I use the paid for product but, from what I remember, you get the same maps with the free version. The difference between the two is that you're limited to 10 (?) maps download in the free version.

They changed this sometime in the last few months. As well as reducing the limit to 7 map downloads total, the maps paid users have access to are now updated faster than the free ones.

What. Reading this thread I was thinking maybe it's time to give OSMAnd another go. Currently using a combination of Maps.me and Google Maps.

But with only 7 map downloads I might as well not bother. Even just the Netherlands is more than 10 map downloads and you probably want at least a piece of Germany too.

On the one hand, OSMAnd felt like it was more accurate or well-behaved in some sense. But the interface was just so confusing (a few years ago), there were a couple of unlabeled icons for its major functions that were (to me) just too generic and could mean any of map/directions/route/search/location related. Even after a long period of use I found myself confusing these icons, having to tap-and-try and navigate (hah) myself through the navigation app.

... so did I understand correctly that the F-Droid version of OSMAnd does not have the 7 map limitation either?

Re: OpenStreetMap Is in Trouble

#282
post #276

Earlier quoted context omitted.

The core editing API hasn't changed in years. HTTP/1.1 come out in 1997 and HTTP/2 in 2015. Was web programming in 2014 the same as web programming in 1998?

Have you ever designed and implemented a modern api? It doesn’t work like that. HTTP itself is fundamental and a different level of abstraction. We would not want monthly updates. A closer analogy is Wikipedia (see wikimedia api). It hasn’t had the fastest evolution, but it makes OSM look like the stone age. You could look at the github api as a project that’s invested more frequently. And it’s not just because these…

This discussion might be more productive if you laid out what you believe the OSM API being discussed already does and what you think it should do in addition to that.

And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two but is free to lay out the backing database in a way that is optimized for queries and people can run their own instance and so on.

Re: OpenStreetMap Is in Trouble

#283
post #277

Earlier quoted context omitted.

They changed this sometime in the last few months. As well as reducing the limit to 7 map downloads total, the maps paid users have access to are now updated faster than the free ones.

What. Reading this thread I was thinking maybe it's time to give OSMAnd another go. Currently using a combination of Maps.me and Google Maps. But with only 7 map downloads I might as well not bother. Even just the Netherlands is more than 10 map downloads and you probably want at least a piece of Germany too. On the one hand, OSMAnd felt like it was more accurate or well-behaved in some sense. But the interface was j…

It's $10 normally, $5 right now! Not expensive for anyone with a European income (And the same for many other regions).

Not wanting to pay for that is fine, whatever, but it's not exactly over the top for the people building the app and running the map infrastructure to charge a fee.

Re: OpenStreetMap Is in Trouble

#284
post #247

Earlier quoted context omitted.

You mean few small (relatively) communities did this for themselves, because it was obvious no one will think about them and in most cases ordinary user doesn't care much about their input. I am talking about an average map user, globally. If you want global coverage and relying on people to input data, then good luck. I do really like the idea and I wish with all my heart that people would be that generous with thei…

> roads in Japan have no meaning. I've never been to Japan. Can you elaborate?

Means - if you have an address, road name or topography won't help you. Most roads don't have a name, anyways. Not sure about US but in EU it's pretty common that houses are bound to roads so the address encloses road name and house number on this road. In Japan it is different. City is divided in areas, which are divided into smaller areas, all the way down to the building. Even locals often don't know the layout and are unable to tell how to reach the house on next square just by looking at the address.

Re: OpenStreetMap Is in Trouble

#285
post #87

Earlier quoted context omitted.

> Needless to say I quickly gave up on using OSM and turned back to Google Maps--and I'm their perfect use case, a skilled techie with a deep interest in using free software! I can't imagine trying to explain how to use OSM to my mom My mom got an iPhone gifted from my dad, so there's mistake number one (I don't know of any decent OSM apps on that proprietary platform), but for what it's worth, my non-technical girlf…

Actually, Apple Maps uses (or at least used to use) OSM data for certain parts of the world.

Apple is also starting to do work on improving OSM.

https://github.com/osmlab/appledata

Re: OpenStreetMap Is in Trouble

#286

Earlier quoted context omitted.

Have you ever designed and implemented a modern api? It doesn’t work like that. HTTP itself is fundamental and a different level of abstraction. We would not want monthly updates. A closer analogy is Wikipedia (see wikimedia api). It hasn’t had the fastest evolution, but it makes OSM look like the stone age. You could look at the github api as a project that’s invested more frequently. And it’s not just because these…

This discussion might be more productive if you laid out what you believe the OSM API being discussed already does and what you think it should do in addition to that. And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two…

Oh yes, I agree. In fact, I’m taking a close look at the architecture, organizational efficiency and results to form an opinion of the bigger picture. Indeed, I haven’t, scratch that, can’t, even assert an opinion on the article as a whole without doing so.

Then how is this productive you ask? Because for now I’m only drawing much smaller conclusions, which also generalize to most actively developed software. Rich, well maintained APIs tend to be useful. As of yet I see no real explanation of why that doesn’t apply to OSM.

To start, not sure why you mention a central server vs. “separate servers”. SaaS users shouldn’t care, or ideally even need to know whether something runs on 10 or 100 servers.

Maybe instead of separate servers, you meant different companies? Knowing which organization is the provider of each service is paramount. For each provider it’s also important to know something about their business model, reputation, roadmap, and the pros/cons of using multiple providers vs. one stop shopping. It’s important enough that companies like Gartner are paid a truckload of money by SaaS users to analyze these details.

So back to my original point: Most significant and active projects benefit from investing in rich and well maintained APIs.

Take that fact, and add in a domain expert taking the time to write an article asserting it’s indeed a problem relevant to OSM. One person’s opinion is not always a smoking gun. But combined with the fact a 10 year old stale API is so unusual, and the fact that what other companies do is a red herring argument being made, at minimum it sure seems like a bright red flag that warrants better understanding of what’s going on over there.

Re: OpenStreetMap Is in Trouble

#287

Earlier quoted context omitted.

This discussion might be more productive if you laid out what you believe the OSM API being discussed already does and what you think it should do in addition to that. And then you could lay out why those things should be done centrally rather than on separate servers. For example, there is a sophisticated data query api https://wiki.openstreetmap.org/wiki/Overpass_API that keeps up with edits within a minute or two…

Oh yes, I agree. In fact, I’m taking a close look at the architecture, organizational efficiency and results to form an opinion of the bigger picture. Indeed, I haven’t, scratch that, can’t, even assert an opinion on the article as a whole without doing so. Then how is this productive you ask? Because for now I’m only drawing much smaller conclusions, which also generalize to most actively developed software. Rich, w…

I mention a central server vs. “separate servers”. because that's pretty much the only way you could come to the incorrect conclusion of 10 year old stale API.

There's a particular service running on some OSM servers that provides data to editing software and receives changes from editing software and applies those changes to the master database. The primary version number on that api is 10 years old. It has still evolved over that time. But it is not the entirety of the OSM API, it is the OSM editing API, which probably benefits from being at least somewhat stable.

I mean, I guess the basic data model could be changed all the time so that all the tooling had to chase after it, but the only big proposal along those lines is to add an explicit "area" type which would simplify some things (it wouldn't really create room for any new capabilities).

Take a look at the vector tile stack Mapbox has put together if you want to see a new way of working with OSM data that has come about over that same 10 year period. Mapzen and OpenMapTiles have also worked on vector tile stacks.

Re: OpenStreetMap Is in Trouble

#288
post #119

Earlier quoted context omitted.

Investigate Overpass and in particular Overpass Turbo. And really, any strict layering system in OSM would quickly just fall apart into debates of exactly what belonged in each layer. The range of detail captured by OpenStreetMap users in different areas is really far too nuanced to work crammed into coarse, crude "layer" classifications.

How can that be the case? Even with a range of detail, the points on a map have to represent one of a fairly limited selection of types. Even if you keep it high level like "buildings", "roads", etc. it's still a massive improvement over having no layers whatsoever.

> the points on a map have to represent one of a fairly limited selection of types

Absolutely not. Not only is the selection of types huge and full of shades of grey, but an element can be tagged as things from multiple different categories at once (and this is a wonderful feature). Take a browse of the OpenStreetMap wiki sometime. OpenStreetMap data is far richer than a layer model could cope with.

However, let's not confuse this with an editor having a layers-like interface feature to help the user focus on a particular subset of the data. JOSM for instance does this very successfully with the "filters" tool, which I use heavily.

Re: OpenStreetMap Is in Trouble

#289
post #30

Earlier quoted context omitted.

As an occasional OSM editor, I wouldn't really feel good about moderation. My edits are limited basically to my home town (10.000 inhabitants, about 10 sq km) where I am adding unmapped roads (usually agricultural, sometimes new construction) that I "discover" while running. I started doing that simply because Runkeeper's website uses OSM and it was showing me running in the middle of nowhere, while there was actuall…

I've contributed small-time to the Musicbrainz cd database, and I think they do it pretty well. New additions are automatically approved. Edits are accepted or rejected after a voting period (3 days, iirc). If nobody votes, they're approved by default; I believe (but am not certain) they are rejected in the case of a tie. I think the beauty of this system is that it gives complete autonomy with no oversight to indivi…

I may be a bit late to this post but as a contributor to both projects, I think the main difference here is that MusicBrainz is all about trying to prevent data deletions in favour of data merges, which will be resolved to the new object while OSM pretty much only cares about the look in the end.

So in OSM it's perfectly acceptable to delete an object and re-create it whereas in MusicBrainz deletions are very much frowned upon.

This means that you often can't really track changes to a single OSM object which would be pretty much necessary for implementing robust rollback behaviour.

Re: OpenStreetMap Is in Trouble

#290
post #119

Earlier quoted context omitted.

Investigate Overpass and in particular Overpass Turbo. And really, any strict layering system in OSM would quickly just fall apart into debates of exactly what belonged in each layer. The range of detail captured by OpenStreetMap users in different areas is really far too nuanced to work crammed into coarse, crude "layer" classifications.

How can that be the case? Even with a range of detail, the points on a map have to represent one of a fairly limited selection of types. Even if you keep it high level like "buildings", "roads", etc. it's still a massive improvement over having no layers whatsoever.

In OSM objects have zero or more tags, a set of key/values (with both being strings). That's all. With that, the OSM community has come up with lots of ways to classify and tag things.

e.g. the railway nerds have very detailed ways to tag railway infastructure: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging

Post reply on HN