I am using Overpass API.
I have an issue to find some points of interest (cafes, hospitals, schools) near (around in 100-200 miles) my point. I have only latitude and longitude.
Overpass API gives opportunity to get POIs using your place name. But I don't have it. I have only coordinates.
How can I do that ?
Use the around statement!
<query type="node">
<around lat="..." lon="..." radius="..."/>
<has-kv k="amenity" v="cafe" />
</query>
<print />
Try this example on overpass turbo!
Related
I have a problem like this: I have a list of latitude, longitude pairs and for each one of those, I would like to know which type of road was it generated on.
All the points are from GPS units of cars driving on public roads.
I have downloaded OpenStreetMap .osm export, where the roads are stored in a format as follows:
<way id="88596345" visible="true" version="9" changeset="453983438" timestamp="2017-05-04T15:47:48Z" user="wegavision" uid="453845">
<nd ref="456877786"/>
<nd ref="3335483999"/>
<nd ref="248335839"/>
<nd ref="406453920"/>
<nd ref="25808860"/>
<tag k="destination" v="abcd"/>
<tag k="highway" v="secondary"/>
<tag k="lanes" v="1"/>
<tag k="lit" v="yes"/>
<tag k="maxspeed" v="30"/>
<tag k="oneway" v="yes"/>
<tag k="ref" v="M54"/>
<tag k="sidewalk" v="left"/>
<tag k="smoothness" v="good"/>
<tag k="surface" v="asphalt"/>
</way>
Now my question is, is there any tool to find a match between GPS coordinates and this way ids? How is this done using OpenStreetMaps?
Okay, so in the end I figured it out as follows:
First, I have installed an Overpass API on my Ubuntu machine and loaded the downloaded .osm there. Then I could query the loaded .osm file like this:
/some_path/osm-3s_v0.7.54/bin/osm3s_query --db-dir=/some_path/osm-3s_v0.7.54/mydb <<< "way['highway'](around:10,'_GPSLAT_,_GPSLON_');out;"
This returned an XML string where I could parse for a way id.
The major issue with this approach is that when your GPS point is close to multiple roads, you get an XML response with multiple way ids. In my solution I have totally neglected this and I am fine with any error this might give. Since my dataset is very large and dense I assume the error made would not be significant and early experiments proved me right.
I'm trying to figure out if Overpass-API's bbox-query should be returning ways that:
Are entirely enclosed by the box (all nodes are inside the box)
Have at least one node inside the box.
At least one segment intersects with the box (even if no nodes are actually inside it).
The docs suggest that it should do #3.
http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide#Bounding_box_clauses_.28.22bbox_query.22.2C_.22bounding_box_filter.22.29
A way is found not only if it has a node inside the bounding box but also if it just crosses somewhere the bounding box.
But, in practice I'm seeing that it's basically only #1.
Which is much less useful as that makes it difficult to make sure you've got all the ways which affect your bounding box.
I think I misunderstood. It does seem to return the ways that only intersect, ie #3, even if they have no nodes in the box. But I was confused because in my query I was also getting nodes and doing a union. It doesn't get the nodes for the way so Overpass-Turbo UI can't render the way. By recursing down, it gets the nodes as well and shows what I expect.
I was further confused because I was doing a query for relations as well, which finds many intersecting relations.
For example
<osm-script output="xml" timeout="25"><!-- fixed by auto repair -->
<!-- gather results -->
<union>
<query type="way">
<bbox-query w="-79.39941" s="43.64019" e="-79.39798" n="43.64120"/>
</query>
<query type="node">
<bbox-query w="-79.39941" s="43.64019" e="-79.39798" n="43.64120"/>
</query>
</union>
<union>
<item/>
<recurse type="down"/>
</union>
<!-- print results -->
<print mode="meta" order="quadtile"/>
</osm-script>
I am using overpass turbo web http://overpass-turbo.eu/#
after typing in
[out:csv(::lat,::lon;false)];
relation(2081626);>;out;
I get already a list of coordinates, under "data" tab
48.0786156 11.5510212
48.0769149 11.5502003
48.0763526 11.5505930
48.0768127 11.5502292
48.0761811 11.5499233
...
How could I plot this list of coordinates on "Map" tab as a route, on the map
try this Overpass XML
<osm-script>
<id-query ref="2081626" type="relation"/>
<union>
<item/>
<recurse type="down"/>
</union>
<print/>
</osm-script>
It appears from the MediaWiki API:Query page that you can only resolve a redirect one at a time.
The document even says "The example below isn't really useful because it doesn't use any query modules, but shows how the redirects parameter works."
But how can you get the redirect information -- using a query module that does return multiple results?
If you have any result that returns pages, then you can just append redirects to the query and it resolves the redirects. If you don't have results that returns pages, you can usually convert it to that by using a generator.
For example, the query
http://en.wikipedia.org/w/api.php?action=query&list=categorymembers&cmtitle=Category:Redirects_from_gender&redirects
returns something like (shortened)
<api>
<query>
<categorymembers>
<cm pageid="648" ns="0" title="Actress" />
<cm pageid="19887132" ns="0" title="Administratrix" />
</categorymembers>
</query>
</api>
If you convert that into a generator
http://en.wikipedia.org/w/api.php?action=query&generator=categorymembers&gcmtitle=Category:Redirects_from_gender
you get
<api>
<query>
<pages>
<page pageid="648" ns="0" title="Actress" />
<page pageid="19887132" ns="0" title="Administratrix" />
</pages>
</query>
</api>
And if you now add redirects
http://en.wikipedia.org/w/api.php?action=query&generator=categorymembers&gcmtitle=Category:Redirects_from_gender&redirects
you get
<api>
<query>
<redirects>
<r from="Actress" to="Actor" />
<r from="Administratrix" to="Administrator (law)" />
</redirects>
<pages>
<page pageid="21504235" ns="0" title="Actor" />
<page pageid="6676496" ns="0" title="Administrator (law)" />
</pages>
</query>
</api>
You can also use prop=redirects with any generator, e.g. generator=allpages. This is a new feature since MW-1.23, fixing bug T59057.
When using generator=allpages with max limits (gaplimit=max and rdlimit=max) and apihighlimits right is available, all redirects on ArchWiki are resolved in a single query ;)
https://wiki.archlinux.org/api.php?action=query&generator=allpages&gapfilterredir=nonredirects&gaplimit=max&prop=redirects&rdprop=pageid|title|fragment&rdlimit=max
I've got SOLR up and running, indexing data via the DIH, and properly returning results for queries. I'm trying to setup another core to run suggester, in order to autocomplete geographical locations. We have a web application that needs to take a city, state / region, country input. We'd like to do this in a single entry box. Here are some examples:
Brooklyn, New York, United States of America
Philadelphia, Pennsylvania, United States of America
Barcelona, Catalunya, Spain
Assume for now that every location around the world can be split into this 3-form input. I've setup my DIH to create a TemplateTransformer field that combines the 4 tables (city, state and country are all independent tables connected to each other by a master places table) into a field called "fullplacename":
<field column="fullplacename" template="${city_join.plainname},
${region_join.plainname}, ${country_join.plainname}"/>
I've defined a "text_auto" field in schema.xml:
<fieldType class="solr.TextField" name="text_auto">
<analyzer>
<tokenizer class="solr.KeywordTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
and have defined these two fields as well:
<field name="name_autocomplete" type="text_auto" indexed="true" stored="true" multiValued="true" />
<copyField source="fullplacename" dest="name_autocomplete" />
Now, here's my problem. This works fine for the first term, i.e. if I type "brooklyn" I get the results I'd expect, using this URL to query:
http://localhost:8983/solr/places/suggest?q=brooklyn
However, as soon as I put a comma and/or a space in there, it breaks them up into 2 suggestions, and I get a suggestion for each:
http://localhost:8983/solr/places/suggest?q=brooklyn%2C%20ny
Gives me a suggestion for "brooklyn" and a suggestion for "ny" instead of a suggestion that matches "brooklyn, ny". I've tried every solution I can find via google and haven't had any luck. Is there something simple that I've missed, or is this the wrong approach?
Thanks!
EDIT: Just in case, here's the searchComponent and requestHandler definition:
<requestHandler name="/suggest" class="org.apache.solr.handler.component.SearchHandler">
<lst name="defaults">
<str name="spellcheck">true</str>
<str name="spellcheck.dictionary">suggest</str>
<str name="spellcheck.count">10</str>
</lst>
<arr name="components">
<str>suggest</str>
</arr>
</requestHandler>
<searchComponent name="suggest" class="solr.SpellCheckComponent">
<lst name="spellchecker">
<str name="name">suggest</str>
<str name="classname">org.apache.solr.spelling.suggest.Suggester</str>
<str name="lookupImpl">org.apache.solr.spelling.suggest.tst.TSTLookup</str>
<str name="field">name_autocomplete</str>`<br/>
</lst>
</searchComponent>
The problem lies in the suggester. Like the spellchecker it tokenizes on whitespace.
http://lucene.472066.n3.nabble.com/suggester-issues-tp3262718p3266140.html has a solution for this problem.
You are using the KeywordTokenizer which will not create separate tokens for "Brooklyn", "NY" and "United States".
Your example queries do not look so much like autocomplete but more like regular searches.
Autocomplete query (IMHO) contains only partial terms:
http://localhost:8983/solr/places/suggest?q=brook
for type ahead lists. You want to use EdgeNGram for that: http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.EdgeNGramFilterFactory
Most probably in combintation with StandardTokenizer and/or WordDelimiterFilterFactory.
For your query example:
http://localhost:8983/solr/places/suggest?q=brooklyn%2C%20ny
StandardTokenizer in combination with LowercaseFilter and dismax request handler with a good configuration of the mm parameter - restricting hits to those that contain all input terms - would work well, see: http://wiki.apache.org/solr/DisMaxQParserPlugin#mm_.28Minimum_.27Should.27_Match.29
I feel the accepted answer is a bit too complex. An elegant way of doing it would be to use http://localhost:8983/solr/places/suggest?spellcheck.q=brooklyn in place of http://localhost:8983/solr/places/suggest?q=brooklyn. As mentioned here