[OSM-dev] OSMXAPI to be ported? (Was Re: Lean and mean Tile- and XML-API-Server)
Stefan Keller
sfkeller at gmail.com
Fri Nov 21 08:54:34 GMT 2008
Thanks, Frederik, for laying out the requirements.
I'm actually after a reliable OSM read-only mirror which offers OSM
api, OSMXAPI and Tiling services as described in the "Lean and mean
Tile- and XML-API-Server" thread. Given many business cases, the data
freshness can be as good as it gets, beginning with weekly/daily
replication.
Stefan
2008/11/21 Frederik Ramm <frederik at remote.org>:
> Hi,
>
> Stefan Keller wrote:
>>
>> So it seems that the OSMXAPI is the candidate which really needs to be
>> ported?
>
> Instead of porting something that exists, why don't you define your needs
> and then simply write something that serves those needs?
>
> OSMXAPI, for example, has a number of special features, e.g. keeping track
> of a list of users having touched an object or "locking" certain tags so
> that only the person having created it can modify it, which are cool to have
> but might be unnecessary baggage for the application you have in mind.
>
> It is also important to know whether you're aiming at some sort of live
> replication (using minute diffs and applying them quickly) or whether you
> are aiming at loading daily diffs; this might also cause you to make
> different design decisions. Systems that can work with minute diffs tend to
> spend more time on initial setup, whereas a system that just loads the
> planet file and is thereafter unable to process minute diffs can load the
> planet much faster.
>
> Another factor is whether or not you need to by XML compatible with the API;
> if it is sufficient for your application to hand out, say, WKT geometries
> then you might go down a different route than if you need to hand out the
> exact data objects.
>
> And so on.
>
> If you are aiming at a read/write environment then it will be hard to
> surpass the current API performance. If you intend to do readonly then
> there's a number of shortcuts you can take.
>
> Bye
> Frederik
>
> --
> Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
>
More information about the dev
mailing list