> I was thinking about adding a 'Query Layer' so you could save such OverPass
> QL queries or even possibly run SQL queries against an OSM Database
> (notionally your own).
>
> Of course using the datasource code is simpler.
The datasource solution i liked because then i could just use a hacky osm
search rather than one i was actually pleased with :)
A query layer would be cool if it could work like a map layer, with the gpx
results being fetched in "tiles". That way you could pan around and have the
search results update on the fly. I was going to start looking in to this at
some point when i get time.
> Indeed 'S' could represent any user runtime specified String, so calling it
> 'Search term' (in the code) is possibly a little too specific.
>
> One may want to use ...node["%s"]... to not limit it to just amenities - then
> you could enter shop=convenience or whatever.
>
> Possibly the UI string displayed could be made XML property too, defaulting
> to 'Search term' if nothing is specified, however that is not that important.
Agreed. I was wondering whether it might be worth building a dedicated open
street map search dialog. It would be nice to have a single search term where
the user can simply enter a name (e.g. "Joe's Diner") or category (e.g. "pub")
and have the right kind of answer returned, but i think something like
overpass QL isn't built for such ill-defined searching.
> It would be good if in the new dialog the text entry widget is given the
> focus, rather than the OK button, thus you start typing straight away. The
> enter key can be made to invoke the accept method. See
> a_prompt_for_goto_string() in vikgoto.c
>
> Also it might be useful to save the last used text (for the Viking session),
> so you can run the query again. Again similar to last_goto_str in vikgoto.c
These would both be good, and hopefully easy to add.
> > Further, as part of this, i've added another property
> >
> > babel_filter_args
> >
> > where the user can specify in datasources.xml some command line arguments to
> > pass to gpsbabel to refine the output. I have a reason for wanting to do
> > this, but will spare you a rambling explanation unless you'd like to hear it
> > :)
>
> I'd like to hear it!
>
> You don't use it in the example below.
>
> I don't understand the "%5$s", surely just "%s" is sufficient.
This is related to what you said below about 10% of pubs being listed as ways.
I cut down the example for simplicity, but then accidentally left in some
detail that became redundant. The original url i was using is
http://overpass-api.de/api/interpreter?data=[bbox:%s,%s,%s,%s];(node[amenity="%5$s"];way[amenity="%5$s"];);out%%20center;
so it searches for both nodes and ways (thus the %5$s). The "out center"
means that the result for a pub that is a way includes a "center" tag. I had
a patch accepted to gpsbabel that outputs way center tags as waypoints, so
both pubs as nodes and as ways come back ok for Viking.
The problem, however, is that pubs listed as ways are also translated to
routes by gpsbabel (and reasonably so, i think). This means that the search
results would be full of routes (with 0 route points) as well as waypoints.
The filter arguments were so i could add
-x nuketypes,routes,tracks
so that only the waypoints made it through to Viking. I figured any general
datasource might also need a few tweaks to gpsbabel output, hence the tag.
Best,
Matt
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/
