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>
Hey,
I've got the SlippyMap [0] JS working with Maps [1]. Althoguh it's working, it's missing handling for some of the parameter users can use to customize maps of other services, like the controls they want on the map, or in case of OpenLayers, the layers they want to have available.
My question is which of the things should be implemented. I am creating this OSM service mainly for the mapping implementation for WM, so it makes sense to have it optimized as much for WM usage as possible. I'd appreciate it if someone who is 'responsible' for the outline of the mapping implmentation contacts me [2] about this.
In any case, once version 0.4 is released, which won't be long any more, everyone will be able to see how the OSM service is currently implemented, and give feedback on that. I'd like to have Maps suitable for WM usage by version 0.5 though.
[0]http://www.mediawiki.org/wiki/Extension:SlippyMap
[1] http://www.mediawiki.org/wiki/Extension:Maps
[2] http://www.mediawiki.org/wiki/User:Jeroen_De_Dauw#Contact_info
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!
Hey,
Since the discussion about the use of the Maps extension [0] to display
(static) maps, part of the identified work to make Maps suitable for this
purpose has been done.
These are the big todo's, and their current status:
* Make Maps completely modular, to enable removing any part of the
functionality that's not wanted, and ensure optimal performance.
This todo has been completed, partly in the last Maps release, 0.3.4, and
partly in the code for the next version. Things that can now be taken out
since they use a hook like system:
- Mapping services (so if we only want OpenLayers with OSM, no problem!)
- The big 'features'. If you don't want geocoding, parser functions,
semantic result formats or form inputs, just remove an includes.
- Geocoding services. If you don't want the Google Geocoder service, just
remove it, and use one of the others.
- Parser functions. Maps only supports display_map and display_point ATM,
but others (like display_route) can easily be added, and of course all of
them can be removed.
* Make maps able to display maps without any markers.
This functionality has been added, and is on SVN trunk [1]. It'll be part of
the upcoming 0.4 release [2] of Maps. Displaying a map with no markers can
now be done with the display_map parser function (maps with markers use
display_point(s)), which is handled by classes that only have the required
code for displaying a Map.
* Add an OSM optimized OL service.
The current code that handles OL in Maps is not optimized for OSM. Also, I
suspect the JS is far from optimal, even if you don't specifically look at
OSM handling. I've just started on this todo, and am attempting to re-use as
much of the smart things done in SlippyMap. This is the final todo before
the 0.4 release.
* Add static map support.
No work has been done here yet. This is currently the only todo for v0.5.
Does anyone have remarks on the current code, or the way I'm planning to
adapt Maps? Also, are there things I'm missing in the list of requirements
for Maps to be suitable for WM usage?
Also, if anyone feels like helping me with the OSM optimisation or static
map functionality, or doing it yourself, just give me a poke, and I'll be
happy to coordinate efforts :)
[0] http://www.mediawiki.org/wiki/Extension:Maps
[1] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Maps/
[2] http://www.mediawiki.org/wiki/Extension:Maps/Future#Maps_0.4
Cheers!
Jeroen De Dauw
Hello, I work the last two weeks on scripts that can show special
map-features for an area (bbox) on openlayers:
http://cassini.toolserver.org/~kolossos/streetlist/frames?bbox=13.54,50.95,…
(example Streetlist of Dresden)
With additionally parameters you can see also other objects than
"key=highway", so in the example you can see all rivers near Dresden:
http://cassini.toolserver.org/~kolossos/streetlist/streetinmap3.php?BBOX=13…
So you can see that this development goes in the direction of
Query-to-map[1] but is independent from Xapi and Google-API.
It was the question of 80n how fast a PostGIS solution can be, and I'm
really happy with the speed of the script. Database speed is not
everyting, in the past Query-to-map use a long running XSLT process to
transform OSM-XML to KML. Now I don't need this process because PostGIS
has nice functions to transform geometry to KML/GML or SVG. You can look
in the source code of my main scripts [2]. The other scripts are nearly
only simple html/js.
I use the "gis"-database on cassini which is used for our mapnik. I the
moment I use only the table "planet_osm_line". Could I get please some
indexes on columns like "name", "ref" and "highway"? I believe this
would optimize the perfomance further. Could we get for all common keys
[3] a column in the database?
Because I use KML you can use the same script also in GoogleEarth:
http://cassini.toolserver.org/~kolossos/streetlist/Netzwerk-Link-OSM-Map-fe…
It shows powerlines on Google Earth and reload after 5sec. when you stop
the camera and reloads with your actual BBOX. You can change the URL to
use it for other map-features.
To-Do list:
*Expand it the script to POI, areas and relations. Whats the best way to
do it? A UNION-sql command or a view in the database with all 4 kinds of
objects?
What a look should POIs have?
*Find the bug to get also the highest zoom-levels in Openlayers.
*Prove the database layout to optimize speed. (I have 2 weeks of
postgres experience, who has more? ;-) )
*Using perhaps the caching system like that of Query-to-map.
*Perhaps Openlayers is faster if I would use Mercator-projection inside
the KML.
*Documentation.
*Develop a stable & flexible URL schema to link of the spripts.
*For the street list: Usage Ajax instead of frames to speedup the
script. I the moment I replace the whole map. Who can help?
Use a A-Z register with the first
letter of the name to jump to the right position on the long list.
Who can work with me to make the script so strong, fast and secure that
it can be move to the productive wikimedia server system and be a part
of the map integration in wikipedia. My idea is that wikipedia editors
can add a map to an article and add some parameter to show really the
object of the article in the map. This would be for me thousand times
more fascinating than to show only the pure map. A new kind of
geocoding. But for this we would also need a process to render this
feature on the static map.
Greetings Kolossos
[1] http://wiki.openstreetmap.org/wiki/Query-to-map
[2]http://cassini.toolserver.org/~kolossos/streetlist/index-source.phphttp://cassini.toolserver.org/~kolossos/streetlist/street-to-kml2-source.php
[3]http://wiki.openstreetmap.org/wiki/Map_Features
Hello, we had this discussion in the past.
Could we get a XAPI-instance[1] on one of our servers?
I would like to use it for my Query-to-map project[2]. For other people
this service is also usefull.
In the moment the XAPI is so slow (2 kbit/s) that my script is
out-of-service.
I want to create a tool that shows the street names of all streets in a
bbox.
Every paper city map has such a list, so it seems usefull.
My first, basic step in this direction is the script "streetlist"[3].
(It use gis database on cassini table "plane_osm_roads". )
Than all entries in this list should be link to Query-to-map, so that
the user could see the streets in the map.
For this I would also need a running XAPI.
Because cassini had too few hard drive space the right place for XAPI
would be IMO on Ptolemy.
Who could decide this? Saper?
Other question, could cassini get more hard drive space? How usefull
would it be?
The concept of the the three servers usage is now other than on the
beginning.
Greetings Kolossos
[1]http://wiki.openstreetmap.org/index.php/Xapi
[2]http://wiki.openstreetmap.org/wiki/Query-to-map
[3]http://cassini.toolserver.org/~kolossos/streetlist/
can be useful ...............
Begin forwarded message:
Date: Wed, 30 Sep 2009 17:06:02 +0100
From: Brian Quinion <openstreetmap(a)brian.quinion.co.uk>
To: OpenStreetMap Geocoding <geocoding(a)openstreetmap.org>
Subject: [Geocoding] New geocoder test system
Hi,
After several false starts the goecoding tool I've been working on
seems to have succeeded in indexing the full planet file and it is now
available for people to experiment with here:
http://katie.openstreetmap.org/~twain/
Data is from 2 weeks ago (approx.) and will remain as is for a week or
so so people can try things after which I'll be using it as a test
system to try importing the daily diff files.
There are still several known problems:
1) No suggestion for miss-spelt words
I have code that produces suggestions but have not yet written the
interface for it.
2) Ordering of citys / towns by size
This is currently disabled because it is taking too long to index for
the planet. I hope to bring it back online shortly.
3) Filtering by viewbox
Currently broken and disabled (again)
4) Ordering of POI by distance
It finds the 10 nearest points (pub, station, whatever) but then
re-sorts them into an arbitrary order. It's an apples and oranges
problem caused by trying to order the points by a combination of
distance and importance and I'm still working on it.
5) 'more'
At the moment the code only shows up to 10 results and there is no way
to get more.
6) wrong name translation shown
Where the feature has names in other languages but not in the local
language (i.e. 'name:cy', but no 'name:en' only 'name') it can end up
showing the wrong version of the name. This is because I've not been
able to find a list of default languages for each country - if anyone
knows of such a list this is easily fixed!
7) Repetition in search results
Hopefully this is mostly fixed however some repetition is still
present where a road is in multiple areas / postcodes or where the
data is actually duplicated in OSM (I've avoided hiding the OSM
duplication so that problems can be found and fixed rather than just
hidden).
Please report other bugs to me either using the reporting tool built
into the site, by email or on IRC in #osm-geocoding. Before reporting
problems with addresses place check how the address was created using
the 'details' link next to each search result. The best way to
improve address information is to either create administrative
boundaries or convert places points into place areas (otherwise it has
to resort to 'nearest' which is always going to have problems).
In addition to HTML view results can also be retrieved in xml or json
format by adding 'format=xml' or format=json paramater to the url,
for example:
http://katie.openstreetmap.org/~twain/?format=xml&q=london
Feedback and bug reports, particularly regarding problems with
non-english searching appreciated.
--
Brian
_______________________________________________
Geocoding mailing list
Geocoding(a)openstreetmap.org
http://lists.openstreetmap.org/listinfo/geocoding
--
Jorge Luis Chamorro <chamorro(a)plug.org.ar>