On Tue, Oct 6, 2009 at 9:57 PM, Tim Alder
<tim.alder@s2002.tu-chemnitz.de> wrote:
XAPI has real nice functionallty. I.e. if you want to know the path of a
long river or a street, you can get it simple and fast via XAPI, also if
this object has more than one way.
With OSM API instead you need to download ALL datas in a bbox and filter
than and the bbox-size is very limited. So I could NOT work with the
normal OSM-API for Query-to-map or something else.
The XAPI runs for a long time very well, so the software seems ok und we
should give it a chance. If it makes too much problems we can stop the
experiment each time. I know that the highest priority project part is
to get the OSM-maps into Wikipedia, so if XAPI installation would be a
real problem for the live system, we should stop it.
(Only an idea: Perhaps XAPI could run only on one core and reduce so
the risk for the stability of the whole system. )
If we would have enough harddrive space we could run XAPI on cassini
instead of ptolemy, there we could also try to program the XAPI
functionality with Postgis on
an optimize database layout. (For my application I don't need timestamp
and editor for each node, so we can perhaps reduce the space
requirements.)
I suspect a Postgis version of XAPI would be slower, but I have no hard evidence of this.
It would be very easy to eliminate unneeded tags from a Wikipedia specific version of XAPI. The attributes user, timestamp, changeset and version are probably all unnecessary. And tags such as created_by, tiger:* and other import meta-data could be suppressed.
80n
Other maps need perhaps also alternative database
layouts and so need alternative layouts. More space we could also use to
save tile for lower zoom levels of our experimental maps, etc.
Greetings Kolossos
Marcin Cieslak schrieb:
> Do you think you could use normal OSM API (instead of XAPI) for your projects?
>
> I don't know - what do you plan to use the extra space for?
>
>