On Tue, Oct 6, 2009 at 9:57 PM, Tim Alder tim.alder@s2002.tu-chemnitz.dewrote:
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?
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l