Hey Ian, all of these things already exist as part of other tools.
The story of OSM :). JXAPI is awesome. The purpose of this JSON-work would be to have a JSON API that is read/write and that is 'the API' on osm.org. If it's possible to add writing to JXAPI, that might be a better technical path to go down? TagInfo's API is certainly pretty good, and it might be good enough. Possibly this would be taginfo, or just a very small subset of what taginfo provides - my general objective is to reduce the number of apis and types of apis you need to understand & count on being stable in order to write an editor. There's more than one technical way to get there. On Thu, Oct 11, 2012 at 3:31 PM, Ian Dees <ian.d...@gmail.com> wrote: > Tom, all of these things already exist as part of other tools. > > JSON formatting and filtering for API endpoints exist as part of jxapi ( > https://github.com/iandees/xapi-servlet). > > TagInfo has an API that's fairly well done. What did you have in mind to > improve it? > > On Thu, Oct 11, 2012 at 2:26 PM, Tom MacWright <t...@macwright.org> wrote: > >> Hey dev, >> >> Just posted the first few issues of the work that I can deem 'stuff that >> we're doing as part of the Knight iniative'. They consist of API-related >> tasks, some of which have had prior art but haven't been tested/completed >> enough to ship. I'd like to get them done and shipped to make some >> substantive improvement in the API. >> >> The first three are: >> >> * JSON formatting for API calls and GeoJSON for some of them. Basically >> just making things friendly for Javascript and other JSON-era languages. >> * Filtering the API endpoints, so that POI editors don't have to sift >> through road data, and so on. >> * A TagInfo-like API for 'commonly used tags' >> >> ( see on >> https://github.com/openstreetmap/openstreetmap-website/issues?direction=desc&sort=created&state=open) >> >> There are a few more tasks to come - stuff like the possibility of an >> Oauth 2 client flow, a complete user API for stuff like user photos & >> stats. Some of the tasks might not be necessary, some might be in need of >> technical reframing (what should be done in cgimap instead?): if you've got >> (constructive) input, please give it! >> >> Tom >> >> _______________________________________________ >> dev mailing list >> dev@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/dev >> >> >
_______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev