Comments (9)
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.
from openstreetmap-website.
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.
from openstreetmap-website.
@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.
from openstreetmap-website.
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.
from openstreetmap-website.
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.
from openstreetmap-website.
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.
from openstreetmap-website.
@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.
from openstreetmap-website.
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 http://lists.openstreetmap.org/listinfo/rails-dev 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.
from openstreetmap-website.
On 10/11/2012 05:37 PM, Tom MacWright wrote:
@zerebubuth https://github.com/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.
I am not sure that is that much of a problem. Assuming you have a
reliable jXAPI which consumes minutely diffs, then you shouldn't be more
than 2 or so minutes behind the main API. Most editors have more than 2
minutes between when they download the data and when they upload the
changes. So any conflict that can come from "unsynchronized" jXAPI can
happen anyway.
In order to detect any conflict you need to upload the version number of
the data you have and the API will only accept the upload if the data
hasn't changed in the meantime.
So having a different read and write API seems fine. Indeed people use
the JOSM mirror download plugin to use alternative servers for the map
call and still push back to the main API.
I suspect the bigger issue is that jXAPI hasn't been as stable as the
main API, so writing an editor that relies on it will equally be prone
to reduced availability. But that is a different issue.
Kai
—
Reply to this email directly or view it on GitHub
#124 (comment).
rails-dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/rails-dev
from openstreetmap-website.
Related Issues (20)
- Automate some code review comments HOT 2
- Wikimedia Commons links with question mark
- Split actions from "lists" in user profile page HOT 2
- Mobile: Hidden close history tab button HOT 5
- Map Data checkbox: perhaps use toggle slider instead HOT 1
- Allow blocks to be hidden HOT 8
- Better handling of version links for an unversioned element view HOT 1
- Add examples to Display Name HOT 5
- Searches for latitudes or longitudes between 1 and -1 result in invalid E-notation numbers HOT 1
- Geocoded address missing from the OSM notes RSS feed HOT 6
- Missing American English localization HOT 10
- Third party logins fail to preserve the referer URL HOT 4
- Unable to Run ESLint Inside Docker Container HOT 2
- Retire activerecord-import gem?
- 'Show address' no longer adds coords to search box HOT 2
- [API] Can not GET/DELETE a preference with a dot in its name. Ex: HOT 1
- Make the Multi fetch response more friendly for hidden versions of objects HOT 3
- Multi fetch for objects histories HOT 9
- NodeJS versions are out of sync again HOT 6
- Add Rate limiting for diary comments HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openstreetmap-website.