DaB. schrieb:
> Hello all,
>
> cassini was reboted because of a kernel-update.
>
> Sincerly,
> DaB.
>
Hum.. as discussed on Maps-L we were just in another planet-import that
would have taken some more hours.. As I can't connect via ssh atm. I'm
unsure if the import was complete at the time of reboot, but I suspect
it wasn't. Hopefully it left the Postgresql-Cluster in a clean state..
re-starting the import would be the minor problem, i think.
Peter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
i'm the senior Unix administrator for the Toolserver project. i'm
mostly involved in the WMF side, and i haven't done much with the OSM
stuff. however, i have been observing the progress of the OSM
Toolserver (cassini), since that is ostensibly part of the Toolserver
cluster, and i have a few concerns.
firstly, i'd like to see proper integration between the OSM and WMF
parts of the Toolserver. for example, someone has configured a web
server on cassini, and people are already deploying tools at
<http://cassini.toolserver.org/~username/>. it should be clear why using
"cassini.toolserver.org" in a URL is a bad idea; but i don't see why
cassini needs to host user tools at all.
the Toolserver already has a web server which works quite well, and has
plenty of spare resources. by putting OSM user tools there, we can
combine resources and make efficient use of them; if/when the web server
is full, we can add additional resources and both WMF and OSM users will
immediately be able to take advantage of them. (i understand OSM needs
some special Apache module for serving tiles; keeping that on cassini
probably makes sense.)
it's also not clear to me whether cassini needs to be a login server at
all; the WMF databases at the TS don't allow user login, and users
connect to them remotely. is there something special about OSM tools
that prevents them from running on the existing TS login servers?
secondly, in the rush to deploy cassini as quickly as possible, it seems
that little planning has been done. one thing we've learnt from the
Toolserver is that it's a lot less effort to plan things properly from
the start, instead of deploying something, then discovering it has to be
redone later. might i suggest that people take a step back, consider
what exactly the "OSM Toolserver" is meant to be, and come up a plan
before going any further?
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkr0AzYACgkQIXd7fCuc5vI9IgCgmrC/Y1klooI0DxmL8SziosO3
OcUAnAw30iUwysYLSnOD6fjTiGDukPW7
=Y5tA
-----END PGP SIGNATURE-----
Hello,
I make some extensions to my streetlist-script so that it gets nearly
the functionality of the old query-to-map script but is independent of
XAPI and GoogleMaps.
It now support point, line and area objects. As example you can see all
churches near Dresden:
http://cassini.toolserver.org/~kolossos/qtm2/queryinmap.php?BBOX=13.5333,50…
If you click on the objects you can get more informations about the object.
And you can get offcourse also a list of it:
http://cassini.toolserver.org/~kolossos/qtm2/featurelist.php?key=amenity&va…
More documention you can found in the wiki:
http://wiki.openstreetmap.org/wiki/Query-to-map
Before I want to promote it for to OSM-community I want to ask, if we
can get an update of the database? And could we get some additionally
columns to the database?
The following keys would be really usefull and are not too much:
cycleway, shop, lit, operator, surveillance, website and wikipedia.
Who can do this?
Greetings Kolossos
BTW: The OSM-Toolserver get a kind of competition:
http://wiki.openstreetmap.org/wiki/FOSSGIS/Server
This can be good for OSM and we can concentrate us perhaps to the
knowledge aspect of OSM and the interface to wikipedia.
<http://dict.leo.org/ende?lp=ende&p=DEdPgA&search=competition>
After a failure to install API database on ptolemy in reasonable amount
of time, I have come to conclusion that we might not need full API database
(ca. ~1 TB) for now, not at least for production Wikimedia use.
What Wikimedia might need is the Mapnik database (ca. 70GB for rendering)
- this is what we have now on Cassini (although outdated - but see neighbouring
thread).
Full API database - once *finally* imported - would have been probably more
useful for tool developers, hacking properties and some other features
of geodata (maybe even history).
However, only Ptolemy (currently WMF production server) has disk space
available for the whole API database; I do not see - but I might be wrong
- currently use for this database (except for genering mapnik DB out of it)
- for the WMF production environment.
So we might have add disk space to Cassini to have space for the full API
database, and start importing it there. But... Maybe we could just switch
servers? (i.e. current Cassini reconfigure as WMF-production Ptolemy and
current Ptolemy reinstall as a toolserver database).
Sure, it will require stopping tools for a while and do some IP (or maybe
even rack-juggling) but maybe it's the solution.
We might alternatively give up on full database API altogether
and just run Mapnik DB on the Ptolemy as we have.
What do you think?
--
<< Marcin Cieslak // saper(a)saper.info >>