Skip to content


Filtering the output of the `map` API endpoint #124

tmcw opened this Issue · 9 comments

6 participants

OpenStreetMap on GitHub member

The core API should support XAPI-style nodes-only, ways-only, etc queries. This might not be the same scope as XAPI, and as a read/write API has more issues, but I'm cool to look through them and see if this would work.

This would constitute a real benefit to limited editors, so that they can pull data from dense areas (read cities) and just edit the data they present (read POIs)

Also, this may be implemented in cgimap instead - @TomH & @zerebubuth have the wisdom there.

OpenStreetMap on GitHub member

This is as really bad idea.

POI editor writers think this is what they want, but it isn't really what they need and it leads to thinks like MapZen POI Collector that encourage the adding of duplicate POIs because they only show nodes and ignore POIs which exist as areas.

@tomhughes tomhughes closed this

Maybe I haven't understood what you're trying to say, but wouldn't using a (j)XAPI instance work just as well?

Firstly, jXAPI already has the functionality to do nodes-only / ways-only queries, including filtering by tag. jXAPI also supports minutely updates so it's unlikely that the data will be seriously out of sync. It seems that duplicating this functionality in the core API would be of little benefit.

Secondly, the OSM representation of a POI could be any one of a node, way or relation with a bunch of different tags, so a limited editor for POIs would need to understand and deal with the complexity of these concepts anyway. For a POI editor it might be the case that a proxy API to translate between "limited" representations and the full OSM data model would be a better solution.

OpenStreetMap on GitHub member

@tomhughes I would appreciate you keeping this discussion open; even if you think this is a bad idea (it certainly might be), it could use some discussion rather than unilateral dismissal. You are not the only contributor or decision-maker for this project.

@zerebubuth The point of this would be to have a read/write API for editors; pulling data from one source and pushing to to another unsynchronized source doesn't seem doable to me, though I could be wrong. This also could amount to just a reliable hosted version of jXAPI that people could use.


Certainly Tom (H)'s point about the Mapzen POI Collector issue is a real one; essentially it fell down where a feature was present in the OSM database as a way outline, but wasn't rendered (either because of collisions or because it simply wasn't in the stylesheet). Since users didn't see it on the tile map display, they then proceeded to add a dupe. It's even more likely to be a problem these days because we have good aerial imagery, so people are increasingly mapping POIs as outlines.

A proxy read-only API is the most interesting idea I've yet heard of solving this, whether running off minutely diffs or chained to the main db servers via some magic replication thingy which is way beyond my paygrade.

OpenStreetMap on GitHub member

I'll reopen this for you @tmcw but personally I really don't think that a bug tracker is the right place to have early phase discussions of potential enhancements.

@tomhughes tomhughes reopened this
OpenStreetMap on GitHub member

Okay, where would be a better place? We both know that IRC and dev@ are filled with flamewars, and the ewg meetings don't have nearly enough time for this sort of discussion.


@tmcw You say unsynchronised, I say loosely coupled ;-)

It's eminently doable - in fact many people already do download jXAPI data, load it into JOSM, edit it and upload it (generally for the purposes of mass automated editing - which I'm very much not in favour of, but on a technical level it's already happening). There's a small lag between jXAPI and the main API which is on the order of minutes, but recent work by Brett means that could come down to seconds.

In any case, the lag associated with data resting in the user's device / desktop is often greater than the lag between jXAPI and the main API. Even when that's not the case, the optimistic locking of the API allows the editor to detect these conflicts and prompt the user to reconcile them.


Re. "dev being filled with flamewars", I believe it's a matter of how you approach such a list. If you come barging in with "here's the improvements I want to push as part of the great kickoff (blog link) for our magnificent Knight initiative" then you might see more headwind than if you said "i've been thinking that these things would be nice to have as building blocks for future work; what do you think, and would the API be the right place for that?". It's something you can, and ultimately have to, learn if you want to work with the community. I think modesty might be the word.

Being more of a mailing list guy myself, I've responded to some of your issues on where these comments seem to be gated to unidirectionally; I'm sorry for the inconvenience but I really can't bring myself to having discussions in the github browser window.

@tmcw tmcw closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.