Hello,
I've been watching for a few months the wonderful development that has been
performed for map internationalization, especially on the Wikimedia
toolserver.
I've been then looking for tools dedicated to this huge task: provide
localities name in specific languages, but so far I found nothing.
Nominatim tool is now in service and it provides very accurate results for
placenames, especially when administrative boundaries are properly defined.
I wonder if Nominatim could be modified, or used as base to elaborate a
translation dedicated tool.
This is the way I imagine it:
_ User considers that he's able to translate placenames in a specific
language (e.g. fr for French) and therefore selects this language in a
dialog box
_ User selects a place name, of a specific admin_level (e.g. Germany, which
corresponds to a level 2 admin_level)
_ Search tool could then return placenames with level 3 (or 4 if 3 is
actually not used) admin_level, that have "Germany" as parent administrative
area
-> For Germany, this should return the list of the Federal states (Länder),
and as far as possible limit results to this, in order to proceed step by
step (first translate country names, then states, ..., cities, streets and
amenities, etc ...)
_ Biggest modification, compared to Nominatim results, is that they would be
provided in two columns
First column returning default name, and a second column used to
1. show names already translated in the language chosen by user (see above)
2. Propose an automated translation (e.g. based on wikipedia contents), for
review and correction
3. allow fill-in of the names translated by user, or allow him to confirm
that translation is not required
4. upload the translations / modifications performed by user in a single
changeset
I guess that this would limit the technical skills required for this
translation task to a minimum, and
This requires that administrative boundaries are properly set-up, for
cleaner results, but this is a task that needs to be achieved anyway !
I am fairly new to OSM and have limited (if any) programming skills.
Don't take it too bad that I'm only able of bringing raw ideas on the table,
and not able of develop them by myself ! :-)
Cheers
and merry Xmas !!
--
ab_fab
Hey Colin,
Thanks for notifying me about the typo.
Maps does not support multiple base layers and overlays for OSM at the moment. So no, you can't get a Hike & Bike map, and you can't activate hillshading or by night layers. I could add support for such things, but then I'd need to know several things:
* What's the datasource for this map? I both need to know where the tiles are fetched for dynamic maps, and where I can get a static version, and what that request should look like.
* How should the base layers and layers be made configurable? Should the user be able to specify them via wiki code or not? And if so, what should that code preferably look like?
* How many of such base layers and layers should be supported? A handful, or multiple dozens?
The OSM maps also do not have special support for printing. If you can refer me to some doc explaining how that works, I'll implement it.
Cheers
--
Jeroen De Dauw
* Forum: code.bn2vs.com
* Blog: blog.bn2vs.com
* Skype: rts.bn.vs
--
Don't panic. Don't be evil.70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
------
Colin Marquardt cmarqu42 at googlemail.com
Mon Dec 21 19:13:31 UTC 2009
While I cannot say anything about the specific questions you raised, I
noticed a typo: in the activatable maps in
http://wiki.bn2vs.com/wiki/Static_map, it says "OpenStreetMaps" with
an "s" at the end - which is wrong :)
I cannot play with the code easily, so I cannot check if it supports
overlays that I would need for
http://toolserver.org/~cmarqu/hikebike.html - check the hillshading
and "by night" layers.
Does it have any special support for printing? Because the attribution
for OSM should then be changed from a clickable "CC-by-SA" link to the
fully written URL. And I guess the attribution should be shown by
default. Some people in OSM are a bit overzealous about that
unfortunately...
Hey,
I'd like to announce the 0.5 release of Maps [0], the extension to be used to display the images and tiles from the WF servers. As I earlier posted on this list, this version supports static map display [1] and error handling, and therefore now has all functionality SlippyMap had. You can find several examples of static maps on my wiki [2].
Some feedback on this would be awesome. Also, in order to further add parameters to get different types of maps, I need to know how I should format the urls, which includes the location of the tile export script, and which parameters it accepts. Without this information, I can not further develop the features that will be used on WF wiki's.
[0] http://www.mediawiki.org/wiki/Extension:Maps
[1] http://www.mediawiki.org/wiki/Extension:Maps#Static_maps
[2] http://wiki.bn2vs.com/wiki/Static_map
Cheers
--
Jeroen De Dauw
* Forum: code.bn2vs.com
* Blog: blog.bn2vs.com
* Skype: rts.bn.vs
--
Don't panic. Don't be evil.70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
Hi
Now that we have a full Histoy Planet Dump (Thank you Lars, Matt and all
who helped with that!), we can again start talking about a History
Server and a History Api.
What I'm thinking of is an extension of the 0.6 API, that includes calls
like this:
GET /api/0.6/[way|relation]/#id/#version/full
GET /api/0.6/node/#id/#version/ways
GET /api/0.6/node/#id/ways?time=#time
GET /api/0.6/[node|way|relation]/#id?time=#time
GET /api/0.6/[node|way|relation]/#id/full?time=#time
GET /api/0.6/map?time=#time
and maybe others like
GET /api/0.6/[nodes|ways|relations]/#id1,#id2,...,#idN
GET /api/0.6/[nodes|ways|relations]/#id1/#ver1/.../#idN/#verN
This would make it easy for a client to fetch the state of a city at any
given time. It would also enable a client to get the complete geometry
of a way or a relation in any given version or at any given time.
This would make it easy to create animations like the "year of edits"
for a town or maybe also a country on demand and with real mapnik styles.
The version-based calls (especially GET /api/0.6/node/#id/#version/ways)
would make it possible to visualize the changes made in a given changeset:
if a way was changed, it is contained with each node and each node's
version, so a client can fetch all those nodes from api and re-build
the way's exact geometry before and after the change
if a node is changed, the ways depending on it are not included in the
changeset and with the current api it's not possible to fetch the
geometry of the ways depending on this node as they were before the
change
I know that there are implications on how versions are counted (one
version of a way could stand for more than one geometry, as its nodes
could have been moved without the version of the way being incremented)
but they can be solved by simply defining sth. like
GET /api/0.6/way/#id/#version/full returns the full geometry of the
way #id, as it was when version #version of was created.
Still all possible geometries of the way could be accessed via the time
predicates.
When taking this idea further, a historic api could even implement
"minor versions" on ways/relations, thus enabling a client to address
any change in the geometry of a way (should read: any change on one of
it's nodes) explicitly.
Such an api could create heavy load on the underlying database, what is
AFAIR the main reason why such calls aren't implemented in the current
api. But unlike on the main api, queries to an such a history api don't
need to be answered in miliseconds. When a /map query for a city on 1st
jan 2007 takes 15 minutes, well that's ok. I's still faster than to
download the corresponding planet dump, import int into postgis and
catch up with the diffs, so what?
My questions to you are
- do you think such an server/service/api would be of use for a greater
audience?
- who would be willing to develop, and who would be able to host such a
service?
- do you think these calls can be implemented without having 10 queries
crash the database?
I think ptolemy, the new-new Wikimedia Toolserver has enough space (2336
GB of raw HD space -- physical, bot logical!) and enough power to run
such an api -- that's why I CCed Maps-L -- maybe Ævar can say if he
thinks this would be possible.
Thank you for reading and commenting,
Peter
Hello, I moved my tools from cassini to normal toolserver and want to
use ptolemy, but the following query (which works on Cassini fine)
brings me the following error. There seems to be a problem with the
transform- correction file:
select osm_id,name,ST_asKML(ST_Transform(way,4326)) from
planet_osm_point where way &&
ST_Transform(ST_SetSRID(ST_MakeBox2D(ST_Point(12.717,50.73),ST_Point(13.117,50.93)),4326),900913)
AND "amenity" like 'fountain' order by name LIMIT 1000;
ERROR: transform: couldn't project point (1.41966e+06 6.5955e+06 0):
failed to load NAD27-83 correction file (-38)
HINT: PostGIS was unable to transform the point because either no grid
shift files were found, or the point does not lie within the range for
which the grid shift is defined. Refer to the ST_Transform() section of
the PostGIS manual for details on how to configure PostGIS to alter this
behaviour.
I hope somebody can repair this.
Greetings Kolossos
Dear subscribers Maps-Listserv.
New Scientist Tech, Dec. 8, 2009 (also featured on www.KurzWeilAI.net).
Crowdsourcing a map of the world and letting anybody edit it (via OpenStreetMap's database) is now more feasible, thanks to some new user-friendly phone apps.
http://www.newscientist.com/article/dn18249-innovation-making-a-map-for-eve…
Crowdsourcing a map of the world, and letting anybody edit it, might sound supremely democratic, but until now it has been a largely exclusive game. Unless you're familiar with cartographic jargon, you haven't been able to play.
That's a pretty big obstacle for the OpenStreetMap project, which wants to generate a map that no government agency (such as the British Ordnance Survey) or commercial entity (Nokia, Tom-Tom, Google and the like) could claim any rights to.
The project kicked off in 2004 and can boast some 180,000 contributors, who have slowly been building the map. But that progress could be supercharged by improvements in cellphone technology and a slew of new apps that can turn anyone into a cartographer.
http://www.openstreetmap.org/
Finally, in case anybody of the Maps-Listserver. is interested in becoming a Wikipedia editor, please reply to my email privately as mentioned.
I trust this information is sufficient for your purposes, in case you require any additional details, please do not hesitate to contact the undersigned.
Awaiting your respons, I remain.
Yours sincerely,
Cordiali Saluti
Marzio Veneman
The Netherlands
Click here to visit my professional profile and connect!
http://www.linkedin-ech3.com/in/Rythmomachyhttp://en.wikipedia.org/wiki/User:Rythmomachy
________________________________
This email message may contain privilliged information and is solely intended for the recipient(s) mentioned above. To ensure that you continue receiving our emails, please add max.rythmos(a)yahoo.com to your address book or safe list.
________________________________
________________________________
Hey guys,
Here is another update on the development of Maps [0], and which requirements for WF usage it does not meet yet. Maps is currently at version 0.4.2, and I'm working on 0.5.
Since my last report [1], which was in late October, I finished the following to-do's:
* Make is able to display maps without any markers.
This functionality was released in version 0.4.
* Add an OSM optimized OL service.
This service was added in 0.4, and supports display_map and display_point. Support for semantic result formats and form inputs will be added to Semantic Maps in 0.5, although that might not be relevant here.
* Add static map support.
I've just done this for the OSM service with display_map, and checked it into SVN. It seems to be working as it should to me. I've stayed relatively close to the SlippyMap code for this, and simply copied a lot of the code. I'm planning on further refining some things, and possibly adding support for display_point for 0.5.
* Add strict parameter validation.
Maps is now able to validate each parameter more sticky, and can give error feedback. The error feedback can be configured via an 'errorLevel' setting that accepts 4 values, enabling you to not show any errors, only a warning if there are any errors, a list of all errors, or a list of all errors and no map. I also rewrote parameter handling in Maps to make it completely modular, and decided to split the code into a separate extension, since it has nothing Maps specific in it anyway. This extension is called Validator [2] and is now required for Maps to function. Both this extension and the strict parameter validation code of Maps are on SVN, but not released yet. That will happen when Maps 0.5 is released.
Together with the tod-o's there where already finished when I did my previous report, these are everything that was mentioned that needed to change to Maps to make it suitable for WF usage. There are probably some more points that will require attention. So can someone involved with the mapping effort that knows the requirements make some time to review Maps with me, so I know what else needs to be done?
I also welcome any suggestions you might have.
[0] http://www.mediawiki.org/wiki/Extension:Maps
[1] http://lists.wikimedia.org/pipermail/maps-l/2009-October/000315.html
[2]http://www.mediawiki.org/wiki/Extension:Validator
Cheers
--
Jeroen De Dauw
* Forum: code.bn2vs.com
* Blog: blog.bn2vs.com
* Skype: rts.bn.vs
--
Don't panic. Don't be evil.70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
previously we had a copy of the OSM mapnik database on cassini. this
database has now moved to ptolemy, and is accessible to all users from
the normal login/web servers. to use it, connect to the "osm_mapnik"
database on the host "sql-mapnik". no password is required.
there is no longer any need to run tools on cassini to access this data,
and cassini will be retired very soon (once tile rendering is available
on ptolemy). people with tools on cassini should therefore move them to
the normal Toolserver.
the OSM data on ptolemy is being updated nightly from the daily diffs.
it's currently a few days lagged, but should catch up in a day or two.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAksXskcACgkQIXd7fCuc5vKQWQCeLAHQB3dh5yTm6RcUqtKWk1ui
v+8AnRyCpXIEJ4AQ8Nq8YxjnjEJ9sDyM
=rRTw
-----END PGP SIGNATURE-----