Re: [OSM-talk] new Wikidata+OSM data in one RDF database

2017-05-12 Thread Eugene Alvin Villar 
So what is the license of this combined database and is this combined
database a whole database or a collective database? Note that Wikidata is
under CC0 while OSM is under ODbL.

On Sat, May 13, 2017 at 12:03 AM, Yuri Astrakhan 
wrote:

> TLDR: A SPARQL (rdf) database with both OSM and Wikidata data is up for
> testing.  Allows massive cross-referenced queries between two datasets. The
> service is a test, and needs a permanent home to stay alive.
>
> Overpass Turbo is awesome, but sadly it does not have data from Wikidata,
> nor does it support some SQL-like conditions. I have setup a temporary RDF
> database that has both OSM & Wikidata. You can use SPARQL queries to find:
>
> * All OSM objects with wikidata tag that references a Wikipedia
> disambiguation page. Get the name of the page in first available language
> ru, fr, de, en.http://tinyurl.com/mzlfb26
>
> * OSM relations with wikidata tag pointing to a person (also tries
> multiple language fallbacks).  http://tinyurl.com/m6fh3wx
>
> * OSM relations with duplicate Wikidata IDs http://tinyurl.com/mvhhogx
>
>
> == OSM data structure ==
> osmnode, osmway, osmrel - OSM object prefix, e.g.  osmnode:1234
> osmt - tag, e.g.  osmt:name:en  (only has tags with latin chars, -, _, :,
> digits
> osmm - meta data about the object -- type, isClosed, version.
>
> I try to preserve OSM data without much changes. Every tag's value is
> stored as a string, except for wikidata and wikipedia tags which are
> converted to a URL, the same format as stored in Wikidata.
>
> osmway:29453885
>   osmt:name "Samina";
>   osmt:waterway "river";
>   osmt:wikidata wd:Q156065;
>   osmt:wikipedia ;
>   osmm:type "w";    could be "r", "w", and "n"
>   osmm:isClosed false;     this meta property is only for OSM ways
>   osmm:version 24.
>
> Wikidata data structure is identical to https://query.wikidata.org (see
> help)
>
>
> == Current limitations ==
> * Only includes OSM objects with either "wikidata" or "wikipedia" tags
> * The OSM data only contains tags with only Latin letters, digits and
> symbols - : _
> * OSM geometry info is not imported, e.g. no center point or bounding box,
> except for osmm:isClosed (true/false) property for ways.
> * Does not include OSM object inheritance data - e.g. cannot query for
> "find a node that is part of a way which is part of a relation that has
> wikidata tag that ..."
> * Wikidata is updated every second, but OSM does not yet update at all,
> imported from a full db dump as of a few days ago.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] new Wikidata+OSM data in one RDF database

2017-05-12 Thread Yuri Astrakhan 
TLDR: A SPARQL (rdf) database with both OSM and Wikidata data is up for
testing.  Allows massive cross-referenced queries between two datasets. The
service is a test, and needs a permanent home to stay alive.

Overpass Turbo is awesome, but sadly it does not have data from Wikidata,
nor does it support some SQL-like conditions. I have setup a temporary RDF
database that has both OSM & Wikidata. You can use SPARQL queries to find:

* All OSM objects with wikidata tag that references a Wikipedia
disambiguation page. Get the name of the page in first available language
ru, fr, de, en.http://tinyurl.com/mzlfb26

* OSM relations with wikidata tag pointing to a person (also tries multiple
language fallbacks).  http://tinyurl.com/m6fh3wx

* OSM relations with duplicate Wikidata IDs http://tinyurl.com/mvhhogx


== OSM data structure ==
osmnode, osmway, osmrel - OSM object prefix, e.g.  osmnode:1234
osmt - tag, e.g.  osmt:name:en  (only has tags with latin chars, -, _, :,
digits
osmm - meta data about the object -- type, isClosed, version.

I try to preserve OSM data without much changes. Every tag's value is
stored as a string, except for wikidata and wikipedia tags which are
converted to a URL, the same format as stored in Wikidata.

osmway:29453885
  osmt:name "Samina";
  osmt:waterway "river";
  osmt:wikidata wd:Q156065;
  osmt:wikipedia ;
  osmm:type "w";    could be "r", "w", and "n"
  osmm:isClosed false;     this meta property is only for OSM ways
  osmm:version 24.

Wikidata data structure is identical to https://query.wikidata.org (see
help)


== Current limitations ==
* Only includes OSM objects with either "wikidata" or "wikipedia" tags
* The OSM data only contains tags with only Latin letters, digits and
symbols - : _
* OSM geometry info is not imported, e.g. no center point or bounding box,
except for osmm:isClosed (true/false) property for ways.
* Does not include OSM object inheritance data - e.g. cannot query for
"find a node that is part of a way which is part of a relation that has
wikidata tag that ..."
* Wikidata is updated every second, but OSM does not yet update at all,
imported from a full db dump as of a few days ago.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Nominatim and waterway relations, broken?

2017-05-12 Thread Sarah Hoffmann 
Hi,

On Thu, May 11, 2017 at 11:04:30AM -0700, Ben Discoe wrote:
> Nominatim has been able to find waterway relations for at least a
> couple years, now.
> 
> For example, if you search "Klamath River", Nominatim's top result is:
> https://www.openstreetmap.org/relation/3624126
> 
> Which is great.  But two days ago, I created another river:
> http://www.openstreetmap.org/relation/7232264
> 
> Searching Nominatim for "Spoon River" currently gives "No results found".
> 
> Supposedly, Nominatim's database delay is small (minutes, not days).
> Anyone know why it's failing to find a large, 2-day-old relation?

It's kind of a bug in Nominatim. The relation is there, see
http://nominatim.openstreetmap.org/details.php?osmtype=R&osmid=7232264
but search doesn't return it properly.

Feel free to stop reading here, but here are the boring details:

The problem is with the importance of the feature computed from the
wikipedia importance. It is lower than the default importance you
get without a wikipedia tag. Now what happens when you search for
the river is that it looks for the first couple of matching results
ordered by importance and it finds all the ways that make up the
relation (which are also correctly tagged with name=Spoon river)
because they have the higher default importance. Rechecking the
result it realises that all those ways are part of a waterway
relation and shouldn't be returned as separate results. So they
all get deleted again from the result list, leaving an empty list.
The relation you are looking for never makes it out of the database.
You can get it, if you ask for more results:
http://nominatim.openstreetmap.org/?q=spoon%20river&limit=50

The proper fix is to remove the ways that make up the relation
from the search index. I'm not sure how simple that actually is. I'll
look into it. Progress can be tracked in
https://github.com/openstreetmap/Nominatim/issues/722

Kind regards

Sarah

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] weeklyOSM #355 02/05/2017-08/05/2017

2017-05-12 Thread weeklyteam 
The weekly round-up of OSM news, issue # 355,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9055/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk