Talk:Query-to-map

From OpenStreetMap Wiki
Jump to navigation Jump to search

Bibliotheken suchen

Cool, sowas hab ich gesucht, um beispielsweise zu suchen nach

Schön wäre natürlich noch, die Anfragen kombineren zu können (nodes und ways sowie mehrer tags). Schöne Grüße -- Nichtich 15:05, 7 July 2008 (UTC)

Hey, so sieht man sich wieder....
Um Nodes und Ways kombinieren zu können müßte ich das Skript recht grundlegend umschreiben. Das Hauptproblem ist aber, dass ich nicht weiß ob ich momentan der API zwei Anfragen zumuten kann/soll. Auch könnte es passieren, dass die Labels der Nodes, kleinere Ways verdecken. Naja, ich werde es mal angehen und testen müssen.
Mehrere Tages zu kombinieren sollte eigentlich mit einem "|" gehen. Ansonsten musst du halt eben Google Earth als Ausgabe benutzen wo du verschiedene Ergebnisse übereinanderlegen und auch farblich editieren kannst. --Kolossos 15:41, 7 July 2008 (UTC)
Und natürlich könnte es einer der größte Nutzen diese Werkzeuge sein, wenn Leute mit speziellen Interessen (wie bei dir die Bibliotheken) spezielle Features abfragen und bis zur Vollständigkeit ergänzen könnnen. --Kolossos 06:53, 8 July 2008 (UTC)

Probleme mit Leerzeichen?

[code]failed to get osm data for query node[ref=A%20648][bbox=8.5,50,9,50.2][/code] Koennte das an dem Leerzeichen liegen?

Nein ganz einfach, die einzelnen nodes sind bei einer Autobahn nicht referenziert, sondern nur die ways. Folgendes ist also richtig:
http://toolserver.org/~kolossos/osm/index.php?way=ref%3DA+648&node=&bbox=&output=osm
Allerdings ist der Toolserver momentan extrem langsam ans Internet angebunden. Prinzipiell geht es aber. --Kolossos 21:52, 15 July 2008 (UTC)

Relationen?

Gibt es ein Template für Relationen um die Verbotszonen von Hannover einzubinden? --jjaf.de 02:59, 27 August 2008 (UTC)

Nein momentan gibt es sowas noch nicht. Aber es müsste wohl nur Template:Osm-query-name kopiert und etwas umgeschrieben. Die Relationangabe funktioniert momentan allerding nur bei Pfaden. Um welches Key/value Paar würde es sich den bei den Verbotszonen handeln? --Kolossos 07:13, 27 August 2008 (UTC)
Die beiden Relationen kennzeichnen sich durch name=Verbotszone Hannover-Oststadt und name=Verbotszone Hannover-Mitte --jjaf.de 21:01, 27 August 2008 (UTC)
Schaust du:Due to changes in Query-to-map this Template does not work anymore. You can use Template:Osm-query2. Please replace or delete this use of Osm-query template. [ dead link ] und Due to changes in Query-to-map this Template does not work anymore. You can use Template:Osm-query2. Please replace or delete this use of Osm-query template. [ dead link ]. Soweit der erste Versuch. --Kolossos 19:40, 1 September 2008 (UTC)
Hervorragend. Vielen Dank. Habe das auf der Seite Hannover eingebaut.

Unable to use a BoundaryBox with Relation search

If you search for a relation, the BoundaryBox will be ignored.

Due to changes in Query-to-map this Template does not work anymore. You can use Template:Osm-query2. Please replace or delete this use of Osm-query template. [ dead link ]

A relation does not contain coordinates, but the nodes of member-ways and member-nodes should be matched against the bbox!

--Phobie 05:48, 12 January 2009 (UTC)

Please test your query against the Xapi it seems the problem is there. I found the same problem at Due to changes in Query-to-map this Template does not work anymore. You can use Template:Osm-query2. Please replace or delete this use of Osm-query template. [ dead link ] --Kolossos 11:52, 12 January 2009 (UTC)
It seems that bbox only works with ways and nodes in Xapi.
--Phobie 05:50, 13 January 2009 (UTC)

A good alternative would be to submit a list of relation ids. Due to changes in Query-to-map this Template does not work anymore. You can use Template:Osm-query2. Please replace or delete this use of Osm-query template. [ dead link ] (http://www.informationfreeway.org/api/0.5/relation[osm:id=50563,50560]) --Phobie 05:50, 13 January 2009 (UTC)

I thought the intention of this query was not to depend on object/relation-IDs from OSM which can change. If you want to use relation-IDs you can link to them directly -- Malenki 19:42, 25 May 2010 (UTC)

Roadmap

I see some ideas and an objective. But what is the project roadmap? When is this planned to be ready? Will it look the same in March 2010 as in March 2009? Is anybody working on this? Is there any progress? Any help you need? --LA2 20:58, 10 March 2009 (UTC)

Feature Request

It would be nice if you can place a Edit link in the pop up window of each POI. Something like in keep right. http://keepright.ipax.at/report_map.php With this we could correct incorrect tags fast. --Zapfen 11:59, 2 April 2009 (UTC)

New Link idea: .. Or a link to the OSM Browse: http://www.openstreetmap.org/browse/node/301006247 like in keepright. --Zapfen 14:42, 14 April 2009 (UTC)

Not a bad idea. A offical page would be nice where you can simple add or delete tags. If such a page would exist I would link to it. --Kolossos 06:00, 16 April 2009 (UTC)
The only way to edit is the link as in keepright to Potlatch - example: http://openstreetmap.org/edit?lat=48.2090016&lon=16.3692293&zoom=18&way=4998699. I think even the OSM Browse would be helpful to. Just to get information about the object. This are both offical pages from openstreetmap.org. Have fun --Zapfen 06:20, 16 April 2009 (UTC)

Problem with new data since api 0.6

It seem the new data added since the new api 0.6 is not found with Query-to-map. It's possible you use the old api? Example: Query to the vending machines for bicycle tubes

Query to map

This one in Basel, Switzerland is not found: Node 391501945

--Zapfen 21:16, 8 May 2009 (UTC)

Thanks for the report. I forced a new request this includes than the bicycle tube in Basel:
http://toolserver.org/~kolossos/osm/osm-paths-gm.php?kml=http://tools.wikimedia.de/~kolossos/osm/cache/bm9kZVt2ZW5kaW5nPWJpY3ljbGVfdHViZV1bYmJveD0wLDAsODksODld.kmz
So it works definetly under 0.6.
It was yesterday that I moved for 0.5 to 0.6. I don't believe that the move back to 0.5 would be the right way, because the update of Xapi 0.5 stopped at 17th april. We have a caching process running at Query-to-map, so we only start a request on XAPI if the datas are older then a month. Perhaps was this the reason. Also Google Maps seems to work with caching [1] and there is a time-gap between OSM-database and Xapi-datas. With "&action=purge&request=Submit" in the URL it should be possible to force new data request. --Kolossos 16:20, 9 May 2009 (UTC)
Excellent, thanks. --Zapfen 11:36, 11 May 2009 (UTC)

weitere Entwickler gesucht

Es besteht die reale Chance, dass das Query-to-map-Projekt im Rahmen der Wikimedia-OSM-Zusammenarbeit direkt in Wikipedia-Artikel integriert werden könnte. Man hätte dort also direkt im Artikel dynamische Karten mit der Hervorhebung von geografischen Objekten und im Artikel wäre einfach nur die Abfrage und ein paar Layoutparameter (Breite, Hintergrundkarte, Linienfarbe) einzutragen. Gleiches gilt natürlich auch für andere Wikis und auch dem OSM-Wiki. Um diese großartige Möglichkeit Wirklichkeit werden zu lassen, gibt es aber noch einiges zu tuen, dafür suche ich Verstärkung:

  • Der derzeitige Lösungsansatz ist zu kompliziert und wenig performant. Die OSM-Daten werden zukünfig für Mapnik sowieso in einer PostGIS-Datenbank im Maps-Toolserver gespiegelt. Es wäre gut wenn man direkt darauf zugreifen könnte. Der Abfragesyntax sollte unverändert bleiben. Wenn dieses aus Performancegründen absolut nicht geht, müsste über eine andere Datenbank nachgedacht werden, ggf. auch die derzeitig von der XAPI genutzte GT.M.
  • Wichtig ist die Umstellung von der GoogleMaps-API auf Openlayers. Daran führt kein Weg vorbei. Es gibt derzeit zwei vorrangige Vorteile der Googlemaps-API, die dazu führen, dass derzeit diese eingesetzt wird. Erstens, wird automatisch auf das KML-Objekt gezoomt. Zweitens lassen sich Punktobjekte anklicken und es geht ein Ballon mit weiterführenden Informationen auf. Beides müßte mit Openlayers gelöst werden, wobei der zweite Punkt auch für die geplante Anzeige von Wikipedia Artikeln auf OSM-Kacheln essentiell wäre.
  • Statt große KML-Dateien an den Clienten auszuliefern, erscheint es alternativ besser das Ergebnis auf die Kacheln in den verschiedenen Zoomstufen zu rendern. Die Idee es so zu machen stammt von Jochen Topf, wie es aussehen könnte und das die Performances stimmen kann, zeigt sein OSM-Inspector.
    Ich habe mal mit Firebug nachgeschaut, und gemerkt, dass es die GoogleMaps-API bei großen KMLs, die für Javascript nicht mehr zu verarbeiten wären, genau so macht und also etwas trickst. Beweis: [2] Damit erscheint es auch einfacher alle Browser und ältere Rechner bzw. Mobile Geräte zu unterstützen. Für das Rendern der Thumbnails, welche in Wikipedia-Artikeln angezeigt werden, ist ein serverseitiges Rendering sowieso von Nöten.

So, ich denke mal, das ist das was ansteht. Mir fehlt es etwas an Zeit und an Erfahrung mit PostGIS, Geoserver, Mapnik, Openlayers und Co. und würde mich daher über Unterstützung freuen. Wenn sich diese im deutschsprachigen Umfeld nicht finden sollte werde ich den Text später wohl mal ins englische übersetzen. --Kolossos 17:30, 23 May 2009 (UTC)

Das hier scheint das Zoomen zu erledigen (im Beispiel erst selber ein paar Features einzeichnen): http://trac.openlayers.org/wiki/Addins/ZoomToFeatures --Colin Marquardt 20:15, 2 June 2009 (UTC)
Das ist wohl das kanonische Popup-Beispiel: http://openlayers.org/dev/examples/sundials-spherical-mercator.html --Colin Marquardt 20:23, 2 June 2009 (UTC)

Na, da scheint sich ja einiges getan zu haben. Mir war jetzt auch aufgefallen, daß es unter dem offiziellen Browser für Punkte, Wege und Relationen (z.B.: http://www.openstreetmap.org/browse/relation/67827) mittlerweile dynamisch zoombare Karten gibt. Super. --Kolossos 20:30, 3 June 2009 (UTC)

Does it work for nodes on ways

I was trying to run it for node=barrier=cycle_barrier, but it doesn't seem to work. Is this because these are nodes on ways, rather than separate nodes?

--RichardMann 14:58, 8 July 2009 (UTC)

You can see it on Platform_Status that the Xapi is not running well in the moment. Xapi is the base for my script. We work in the moment to get the Xapi on a fast wikimedia-server. Than you can try it again. It should work than. --Kolossos 15:09, 8 July 2009 (UTC)

Modifizierte Version des XSL Stylesheets mit Icons bei Ways

Ich habe auf die Version von hier aufbauend ein paar kleine Erweiterungen gemacht.-> http://www.its-here.net/osm/

  • Bei Ways wird nicht nur der Way selbst dargestellt, sondern auch ein Pin Icon im geographischen Mittelpunkt.
  • Die Icons haben im Popup Informationen zu ID, Timestamp, User und Name
  • Ein bisschen cleanup im Stylesheet für die ways.

Beispiel KML Output: http://maps.google.de/maps?q=http://its-here.net/osm/baum%C3%A4rkte2.kml (aus ways mit shop=doityourself in Wien)

Schön. Ich habe für das Projekt meine ersten Schritte in XSLT gemacht und nur das nötigste umgesetzt. Ein Zeilenumbruch nach jedem Parameter wäre schön und alle anderen Parameter eines Nodes sollte man auch sehen.
Deine Ways konnte ich mir nicht anschauen, hast du einen Link? Wie sieht das ganze bei langen Straßen aus, die wegen Brücken aus mehreren Ways bestehen? Ich bin mir noch nicht ganz sicher, ob die Marker nicht zu oft die Ways überdecken.
Bitte mach weiter. Übrigens finde ich Rot besser ins Auge fallend. --Kolossos 15:35, 13 August 2009 (UTC)
War es so gedacht das mir die fertigen XSL nehmen kann? Dann würde ich das soweit dankend annehmen. Übrigens kannst du auch einen eigenen Account auf dem Toolserver beantragen, wenn du tiefer in das Thema OSM einsteigen willst. --Kolossos 19:24, 13 August 2009 (UTC)
Bin auch kein XSLT Spezialist, werde aber versuchen deine Vorschläge in den nächsten Tagen einzubauen. Bei langen Straßen oder Flüssen machen die Icons natürlich weniger Sinn, mein Anwendungsfall war eher das suchen von zb. Baumärkten in einer Region und darstellen als Icons sowohl bei Nodes als auch bei Ways (wenn der Tag beim Way des Gebäude).
Und klar kannst du die Stylesheets weiterverwenden, dachte OSM Anwendungen sind alle unter GPL.
Du brauchst aber einen XSLT 2.0 fähigen Prozessor (was xsltproc leider nicht ist). --nevermind 20:40, 15 August 2009 (UTC)

Frage Gebiet

Ich habe mal eine Frage zu dem Gebiet, das man auf eine Anfrage zurückbekommt. Ich benutze diese Anfrage: http://toolserver.org/~kolossos/osm/index.php?way=research_institution&node=&relation=&request=Submit&bbox=&description=

Als Ergebnis bekomme ich nur ways aus Europa. Ist das so gedacht? Lässt sich das auch auf die USA erweitern? --Gkai 09:43, 24 August 2009 (UTC)

Problem with complex key names

I tried getting a map for key=name:sl, but it returns nothing.

Skimming the code quickly it seems that values in $subquery_key should also be urlencoded.

Then again, a request to kml script directly fails with

function.pg-query: Query failed: ERROR:  syntax error at or near ":"
LINE 2: ...int(14,45),ST_Point(16,47)),4326),900913) AND name:sl like '...
                                                            ^ in 
/home/kolossos/osm_public_html/qtm2/osm-to-kml.php on line 17

Which also indicates the script might be vulnerable to SQL injections.

--Stefanb 10:45, 11 November 2009 (UTC)

I put the key into "", now it seems to work. The security question I will talk with a friend, all input goes through a addslashes-command, I believed that this is enough. Thanks. --Kolossos 21:53, 12 November 2009 (UTC)

XAPI-like operation?

Is it possible to use this service to get raw OSM data with complex queries? Like XAPI servers do (when they work, that is, and when they do it right). Not realtime, daily queries. Mikado 19:49, 25 November 2009 (UTC)

Sorry to write a new XAPI is not popsible for me. I don't have the knowledge for that and don't know which database structure would be optimum. But it would be perhaps a good idea to write it new in a language that is common and acceptable for admins. But to get a good performance will not be easy. --Kolossos 21:37, 26 November 2009 (UTC)
User:80n seems to work on a re-implementation of the XAPI in Python. Let's hope it runs on a server which is more stable. --Colin Marquardt 19:37, 28 November 2009 (UTC)
Sounds very good. I hope 80n get than a OK from Toolserver/Fossgis-Serveradmins or from somebody. Do you know which database he want to use in the background? --Kolossos 18:41, 30 November 2009 (UTC)
No, I just heard about the python reimplementation. --Colin Marquardt 00:26, 3 December 2009 (UTC)

Display (all contents of) a relation?

I tried to use this tool to display the objects contained in a relation (type=collection) of Strategischer Bahndamm. I succeeded only partially: [3] I guess name=Strategischer Bahndamm although matching only the relation excludes all objects named otherwise. Any suggestions? -- Malenki 19:57, 25 May 2010 (UTC)

With other relations it works fine, see Linie 7 / Dresden (type = route) in Query-to-map .
Your relation is not in our database so I need to ask if there is something wrong in the import script. Thank you for bug finding (Danke.) --Kolossos 16:31, 26 May 2010 (UTC)
Only "my" relation or the type "collection"? I guess the type is not well known. -- Malenki 17:00, 26 May 2010 (UTC)
Would it be possible for you to changed the relation to type="route" and check it than some minutes later again. For me this case looks like a route, an historical route. It doesn't make sense to store the paths of each type (e.g. turn restrictions) in the rendering-database on the other side I want to have much flexibility on the toolserver. --Kolossos 21:14, 26 May 2010 (UTC)
Of course it would be possible to change the relation. But that would not change the situation that (afais) a certain kind of relation is not supported atm. -- Malenki 19:36, 27 May 2010 (UTC)

Development

Your tool is very valuable (since it has no other equivalent), but it fills only very basic needs and tasks. OpenStreetMap project needs a powerful and robust tool that searches by tag(s) and plots results directly on a map in order for the map to be usable for showing various data on it. I know this might be resource intensive, but such feature has a great added value. Today, I am not able to link to objects that are on OpenStreetMap other that if they are members of a relation (e.g. this template).--Kozuch 17:01, 25 July 2011 (BST)

Less realtime but faster

Hi! I like your/this project, Super! I'm trying to find a good way to illustrate hiking-ways for Wikipedia, better than the screenshot-style of Openstreetmap-relation(s). I see the benefits like possible completition (?) of osm data and the up-to-date information.

Following came to my mind: A little less 'real time' than the query to map approach is the Lonvia-hiking map approach [1]. It seems to use 2 types of databases, one big one with the world data and one just for the extracted hiking data, which (I think) is rendered to tiles, but we can leave the rendering for now.

This is maybe also good for query to map, the actual ways or nodes requested by Wikipedia could be stored in advance and processed on ä ;) an extra server which is another story of course.


Even cheaper and even less real-time is storing a kml in Wikipedia, like the Geographic_Overlays, which seems not to have majority appeal according to Fossgis2009[2], but which can be neatly displayed in OpenLayers at almost no server load. Kml (or gpx) files are also not too difficult for user to make, and still are better than pixel-pictures, no? (Besides I expect that there will be a kml-extension for MediaWiki soon [3] but thats yet another story)


I can't be much of help for the lonvia way, but I'd be glad to (help to) rewrite one of your scripts to make a test-'kml-geo-hack', through I guess there must be some discussion first. Any opinions?

  1. Lonvia OsgendeFramework
  2. Fossgis2009 (german)
  3. Jeroen De Dauw, KML visualisation status

Servas, --Guverneu 14:09, 5 September 2011 (BST)(from AT)

Lonvia is probably similar to OSM Inspector that you mentioned, concerning how it works or at least how it looks like. --schöne Grüsse, Guverneu 17:34, 13 September 2011 (BST)
Send you (german) email. --Kolossos 19:29, 14 September 2011 (BST)

Unexpected results when wild card character used

Compare results of these two queries (one used '*' in value= parameter):

http://toolserver.org/~kolossos/qtm2/featurelist.php?key=name&value=Elgin%20Trail&types=lines&BBOX=-81.4,42.6,-81.1,42.9
http://toolserver.org/~kolossos/qtm2/featurelist.php?key=name&value=Elgin%20Trail*&types=lines&BBOX=-81.4,42.6,-81.1,42.9

The first query presents "Elgin Trail" in left panel; the second query does not. The first query does not hilight a section in middle of trail where name='Elgin Trail (private property)'. Is this a bug; or might I construct a different query to get "Elgin Trail (private property)" to appear in left panel *AND* be hilighted on the map? Fbax 02:56, 7 December 2012 (UTC)

TIP: Using "%" instead of "*" for wildcard appears to resolve this issue (ex: http://toolserver.org/~kolossos/qtm2/featurelist.php?key=name&value=%Bruce%20Trail%&types=lines&BBOX=-81.7,42.9,-78.9,45.3) . Fbax

toolserver.org/~kolossos down?

The site toolserver.org/~kolossos has several links to it on this page; it stopped working (404 error) a few minutes ago. Fbax (talk) 21:32, 22 April 2013 (UTC)

Download map data

Hello there. I would like to know if its possible (on http://toolserver.org/~kolossos/qtm2/featurelist.php ) 

to download the displayed data to an osm file or something.

Thanking you in advance.

queryinmap has no results for some tags

Is there a reason why this tag as key= has empty results? [queryinmap.php?key=surface] is an example that does not work, despite the surface key being shown as valid at [Map_Features]

With the demise of [itoworld], I am trying to find a replacement, and wonder if it's possible to get [queryinmap.php?key=tiger] to work? Thank you