Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Yuri Astrakhan]

OSM+WD service updates:  new examples interface contains just the OSM-related
examples, and they are user-contributable. The osmm:loc (centroid) is now
stored with all objects including relations, so it is now easy to see how
far Wikidata's coordinates are from OSM's - http://tinyurl.com/yd97qtp2 Also,
if a query outputs geo location, it can be shown on an interactive map,
e.g. a map of educational places near Jersey City, with different colors by
type: http://tinyurl.com/y82w6my8 .

Relation members are now stored as  "osmm:has" predicates, linking to the
member object.  Example:   "osmrel:123  osmm:has  osmway:456" -- relation
#123 contains way #456.  The role (inner, outer, ...) of that member is now
stored as   osmrel:123  osmway:456  "inner"   -- meaning relation #123 has
an "inner" way #456 member.  This way you can quickly search for all
relation members of an object -- { ?osmid  osmm:has  ?member . }, or you
can examine the actual role of those members.

Developers, please help with integrating this new engine into MapRoulette
and JOSM.  Also, the service is still looking for a new permanent home, but
there is hope!  http://88.99.164.208/wikidata

Sarah, thanks for your help! I'm now able to calculate centroids for almost
all of the objects. There are still a few broken way objects out there -
they are not stored as linestrings, so i cannot access them via python's
bindings, but there are very few of them.  The data will soon regenerate
with most of the osmm:loc populated.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Mon, Aug 21, 2017 at 05:38:06PM -0400, Yuri Astrakhan wrote:
> Sarah, thanks, I created an issue at
> https://github.com/osmcode/pyosmium/issues/47
> 
> Does this mean I cannot even use the existing node cache file when
> processing ways from the minute diff files from pyosmium?

You can do the updates manually as well. Open the node cache file like this:

mapfile = osmium.osm.index.create_map("dense_file_array," + filename)

and hand it into your handler. In the node() callback make sure you
update the locations in the cahce file like this:

   node(self, n):
 if n.deleted:
   mapfile.set(n.id, osmium.osm.Location())
   else:
   mapfile.set(n.id, n.location)

and then change the way callback to simply use the coordinates of a
point in the middle instead of computing a representitive point
from the full way geometry:

  way(self, w):
ndid = w.nodes[len(w.nodes)/2]
point = wkbfab.create_point(mapfile.get(ndid))

That's out of my head, I haven't tested it and you should be adding
a couple of sanity checks for empty ways and points.

Sarah

> 
> On Mon, Aug 21, 2017 at 4:44 PM, Sarah Hoffmann  wrote:
> 
> > On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> > > Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> > > The idx param is passed to the apply_file() - for the initial PBF dump
> > > parsing, but I don't see any place to pass it for the subsequent diff
> > > processing.  I assume there must be a way to run .apply_diff() that will
> > > download the minute diff file, update node cache file with the changed
> > > nodes, and afterwards call my way handler with the updated way
> > geometries.
> >
> > I don't think that is possible yet. For my own projects I have always
> > used an explicit instance of the node cache file and read and written
> > that manually (using the osmium.index.LocationTable() class). But that
> > is not particularly practical. I'll look into adding an idx parameter
> > to the replication mechanism when I find a minute. Feel free to open
> > a feature request on github to remind me.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> > > case I would use one of these idx values when calculating way centroid,
> > and
> > > None otherwise:
> > > sparse_mem_array
> > > dense_mmap_array
> > > sparse_file_array,my_cache_file
> > > dense_file_array,my_cache_file
> > >
> > > Thanks!
> > >
> > >
> > > On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann 
> > wrote:
> > >
> > > > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > > > mmd, the centroids are calculated with this code, let me know if
> > there
> > > > is a
> > > > > better way, I wasn't aware of any issues with the minute data
> > updates.
> > > > >   wkb = wkbfab.create_linestring(obj)
> > > > >   point = loads(wkb, hex=True).representative_point()
> > > > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> > > >
> > > > It doesn't look like you have any location cache included when
> > > > processing updates, so that's unlikely to work.
> > > >
> > > > Minutely updates don't have the full node location information.
> > > > If a way gets updated, you only get the new list of node ids.
> > > > If the nodes have not changed themselves, they are not available
> > > > with the update.
> > > >
> > > > If you need location information, you need to keep a persistent
> > > > node cache in a file (idx=dense_file_cache,file.nodecache)
> > > > and use that in your updates as well. It needs to be updated
> > > > with the fresh node locations from the minutely change files
> > > > and it is used to fill the coordinates for the ways.
> > > >
> > > > Once you have the node cache, you can get the geometries for
> > > > updates ways. This is still only half the truth. If a node in
> > > > a way is moved around, then this will naturally change the
> > > > geometry of the way, but the minutely change file will have
> > > > no indication that the way changed. Normally, these changes are
> > > > relatively small and for some applications it is good enough
> > > > to ignore them (Nominatim, the search engine, does so, for example).
> > > > If you need to catch that case, then you also need to keep a
> > > > persistent reverse index of which node is part of which way
> > > > and for each changed node, update the ways it belongs to.
> > > > There is currently no support for this in libosmium/pyosmium.
> > > > So you would need to implement this yourself somehow.
> > > >
> > > > Kind regards
> > > >
> > > > Sarah
> > > >
> > > > >
> > > > > Your query is correct, and you are right that (in theory) there
> > shouldn't
> > > > > be any ways without the center point. But there has been a number of
> > ways
> > > > > with only 1 point, causing a parsing error "need at least two 

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Yuri Astrakhan]

Sarah, thanks, I created an issue at
https://github.com/osmcode/pyosmium/issues/47

Does this mean I cannot even use the existing node cache file when
processing ways from the minute diff files from pyosmium?

On Mon, Aug 21, 2017 at 4:44 PM, Sarah Hoffmann  wrote:

> On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> > Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> > The idx param is passed to the apply_file() - for the initial PBF dump
> > parsing, but I don't see any place to pass it for the subsequent diff
> > processing.  I assume there must be a way to run .apply_diff() that will
> > download the minute diff file, update node cache file with the changed
> > nodes, and afterwards call my way handler with the updated way
> geometries.
>
> I don't think that is possible yet. For my own projects I have always
> used an explicit instance of the node cache file and read and written
> that manually (using the osmium.index.LocationTable() class). But that
> is not particularly practical. I'll look into adding an idx parameter
> to the replication mechanism when I find a minute. Feel free to open
> a feature request on github to remind me.
>
> Kind regards
>
> Sarah
>
> >
> > Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> > case I would use one of these idx values when calculating way centroid,
> and
> > None otherwise:
> > sparse_mem_array
> > dense_mmap_array
> > sparse_file_array,my_cache_file
> > dense_file_array,my_cache_file
> >
> > Thanks!
> >
> >
> > On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann 
> wrote:
> >
> > > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > > mmd, the centroids are calculated with this code, let me know if
> there
> > > is a
> > > > better way, I wasn't aware of any issues with the minute data
> updates.
> > > >   wkb = wkbfab.create_linestring(obj)
> > > >   point = loads(wkb, hex=True).representative_point()
> > > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> > >
> > > It doesn't look like you have any location cache included when
> > > processing updates, so that's unlikely to work.
> > >
> > > Minutely updates don't have the full node location information.
> > > If a way gets updated, you only get the new list of node ids.
> > > If the nodes have not changed themselves, they are not available
> > > with the update.
> > >
> > > If you need location information, you need to keep a persistent
> > > node cache in a file (idx=dense_file_cache,file.nodecache)
> > > and use that in your updates as well. It needs to be updated
> > > with the fresh node locations from the minutely change files
> > > and it is used to fill the coordinates for the ways.
> > >
> > > Once you have the node cache, you can get the geometries for
> > > updates ways. This is still only half the truth. If a node in
> > > a way is moved around, then this will naturally change the
> > > geometry of the way, but the minutely change file will have
> > > no indication that the way changed. Normally, these changes are
> > > relatively small and for some applications it is good enough
> > > to ignore them (Nominatim, the search engine, does so, for example).
> > > If you need to catch that case, then you also need to keep a
> > > persistent reverse index of which node is part of which way
> > > and for each changed node, update the ways it belongs to.
> > > There is currently no support for this in libosmium/pyosmium.
> > > So you would need to implement this yourself somehow.
> > >
> > > Kind regards
> > >
> > > Sarah
> > >
> > > >
> > > > Your query is correct, and you are right that (in theory) there
> shouldn't
> > > > be any ways without the center point. But there has been a number of
> ways
> > > > with only 1 point, causing a parsing error "need at least two points
> for
> > > > linestring". I will need to add some special handling for that
> > > > (suggestions?).
> > > >
> > > > You can see the error by adding this line:
> > > >OPTIONAL { ?osmId osmm:loc:error ?err . }
> > > > The whole query --  http://tinyurl.com/ydf4qd62  (you can create
> short
> > > urls
> > > > with a button on the left side)
> > > >
> > > > On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> > > > >
> > > > > > * all ways now store "osmm:loc" with centroid coordinates,
> making it
> > > > > > possible to crudely filter ways by location
> > > > >
> > > > > out of curiosity, can you say a few words on how your overall
> approach
> > > > > to calculate centroids for ways? As we all know it's an endless
> pain to
> > > > > get that information out of minutely diffs :)
> > > > >
> > > > > I have to say that I'm pretty much unfamiliar with SPARQL and just
> > > tried
> > > > > the following query. My expectation was that I won't get any
> results,
> > > > > making me wonder if 

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Sun, Aug 20, 2017 at 11:08:03PM -0400, Yuri Astrakhan wrote:
> Sarah, how would I set the node cache file to the repserv.apply_diffs()?
> The idx param is passed to the apply_file() - for the initial PBF dump
> parsing, but I don't see any place to pass it for the subsequent diff
> processing.  I assume there must be a way to run .apply_diff() that will
> download the minute diff file, update node cache file with the changed
> nodes, and afterwards call my way handler with the updated way geometries.

I don't think that is possible yet. For my own projects I have always
used an explicit instance of the node cache file and read and written
that manually (using the osmium.index.LocationTable() class). But that
is not particularly practical. I'll look into adding an idx parameter
to the replication mechanism when I find a minute. Feel free to open
a feature request on github to remind me.

Kind regards

Sarah

> 
> Also, I assume you meant dense_file_array, not dense_file_cache. So in my
> case I would use one of these idx values when calculating way centroid, and
> None otherwise:
> sparse_mem_array
> dense_mmap_array
> sparse_file_array,my_cache_file
> dense_file_array,my_cache_file
> 
> Thanks!
> 
> 
> On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann  wrote:
> 
> > On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > > mmd, the centroids are calculated with this code, let me know if there
> > is a
> > > better way, I wasn't aware of any issues with the minute data updates.
> > >   wkb = wkbfab.create_linestring(obj)
> > >   point = loads(wkb, hex=True).representative_point()
> > > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
> >
> > It doesn't look like you have any location cache included when
> > processing updates, so that's unlikely to work.
> >
> > Minutely updates don't have the full node location information.
> > If a way gets updated, you only get the new list of node ids.
> > If the nodes have not changed themselves, they are not available
> > with the update.
> >
> > If you need location information, you need to keep a persistent
> > node cache in a file (idx=dense_file_cache,file.nodecache)
> > and use that in your updates as well. It needs to be updated
> > with the fresh node locations from the minutely change files
> > and it is used to fill the coordinates for the ways.
> >
> > Once you have the node cache, you can get the geometries for
> > updates ways. This is still only half the truth. If a node in
> > a way is moved around, then this will naturally change the
> > geometry of the way, but the minutely change file will have
> > no indication that the way changed. Normally, these changes are
> > relatively small and for some applications it is good enough
> > to ignore them (Nominatim, the search engine, does so, for example).
> > If you need to catch that case, then you also need to keep a
> > persistent reverse index of which node is part of which way
> > and for each changed node, update the ways it belongs to.
> > There is currently no support for this in libosmium/pyosmium.
> > So you would need to implement this yourself somehow.
> >
> > Kind regards
> >
> > Sarah
> >
> > >
> > > Your query is correct, and you are right that (in theory) there shouldn't
> > > be any ways without the center point. But there has been a number of ways
> > > with only 1 point, causing a parsing error "need at least two points for
> > > linestring". I will need to add some special handling for that
> > > (suggestions?).
> > >
> > > You can see the error by adding this line:
> > >OPTIONAL { ?osmId osmm:loc:error ?err . }
> > > The whole query --  http://tinyurl.com/ydf4qd62  (you can create short
> > urls
> > > with a button on the left side)
> > >
> > > On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> > >
> > > > Hi,
> > > >
> > > > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> > > >
> > > > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > > > possible to crudely filter ways by location
> > > >
> > > > out of curiosity, can you say a few words on how your overall approach
> > > > to calculate centroids for ways? As we all know it's an endless pain to
> > > > get that information out of minutely diffs :)
> > > >
> > > > I have to say that I'm pretty much unfamiliar with SPARQL and just
> > tried
> > > > the following query. My expectation was that I won't get any results,
> > > > making me wonder if my query has some issue?
> > > >
> > > > SELECT * WHERE {
> > > >   ?osmId osmm:type 'w' .
> > > >   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> > > > } LIMIT 100
> > > >
> > > >
> > > > BTW: A quick search on Github yielded the following:
> > > > https://github.com/nyurik/osm2rdf. Would that be the right place to
> > look
> > > > for more details?
> > > >
> > > > Best,
> > > > mmd
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Yuri Astrakhan]

Sarah, how would I set the node cache file to the repserv.apply_diffs()?
The idx param is passed to the apply_file() - for the initial PBF dump
parsing, but I don't see any place to pass it for the subsequent diff
processing.  I assume there must be a way to run .apply_diff() that will
download the minute diff file, update node cache file with the changed
nodes, and afterwards call my way handler with the updated way geometries.

Also, I assume you meant dense_file_array, not dense_file_cache. So in my
case I would use one of these idx values when calculating way centroid, and
None otherwise:
sparse_mem_array
dense_mmap_array
sparse_file_array,my_cache_file
dense_file_array,my_cache_file

Thanks!


On Mon, Aug 14, 2017 at 4:31 PM, Sarah Hoffmann  wrote:

> On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> > mmd, the centroids are calculated with this code, let me know if there
> is a
> > better way, I wasn't aware of any issues with the minute data updates.
> >   wkb = wkbfab.create_linestring(obj)
> >   point = loads(wkb, hex=True).representative_point()
> > https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250
>
> It doesn't look like you have any location cache included when
> processing updates, so that's unlikely to work.
>
> Minutely updates don't have the full node location information.
> If a way gets updated, you only get the new list of node ids.
> If the nodes have not changed themselves, they are not available
> with the update.
>
> If you need location information, you need to keep a persistent
> node cache in a file (idx=dense_file_cache,file.nodecache)
> and use that in your updates as well. It needs to be updated
> with the fresh node locations from the minutely change files
> and it is used to fill the coordinates for the ways.
>
> Once you have the node cache, you can get the geometries for
> updates ways. This is still only half the truth. If a node in
> a way is moved around, then this will naturally change the
> geometry of the way, but the minutely change file will have
> no indication that the way changed. Normally, these changes are
> relatively small and for some applications it is good enough
> to ignore them (Nominatim, the search engine, does so, for example).
> If you need to catch that case, then you also need to keep a
> persistent reverse index of which node is part of which way
> and for each changed node, update the ways it belongs to.
> There is currently no support for this in libosmium/pyosmium.
> So you would need to implement this yourself somehow.
>
> Kind regards
>
> Sarah
>
> >
> > Your query is correct, and you are right that (in theory) there shouldn't
> > be any ways without the center point. But there has been a number of ways
> > with only 1 point, causing a parsing error "need at least two points for
> > linestring". I will need to add some special handling for that
> > (suggestions?).
> >
> > You can see the error by adding this line:
> >OPTIONAL { ?osmId osmm:loc:error ?err . }
> > The whole query --  http://tinyurl.com/ydf4qd62  (you can create short
> urls
> > with a button on the left side)
> >
> > On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> >
> > > Hi,
> > >
> > > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> > >
> > > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > > possible to crudely filter ways by location
> > >
> > > out of curiosity, can you say a few words on how your overall approach
> > > to calculate centroids for ways? As we all know it's an endless pain to
> > > get that information out of minutely diffs :)
> > >
> > > I have to say that I'm pretty much unfamiliar with SPARQL and just
> tried
> > > the following query. My expectation was that I won't get any results,
> > > making me wonder if my query has some issue?
> > >
> > > SELECT * WHERE {
> > >   ?osmId osmm:type 'w' .
> > >   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> > > } LIMIT 100
> > >
> > >
> > > BTW: A quick search on Github yielded the following:
> > > https://github.com/nyurik/osm2rdf. Would that be the right place to
> look
> > > for more details?
> > >
> > > Best,
> > > mmd
> > >
> > >
> > > --
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > talk mailing list
> > > talk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk
> > >
>
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Sarah Hoffmann]

On Mon, Aug 14, 2017 at 11:10:39AM -0400, Yuri Astrakhan wrote:
> mmd, the centroids are calculated with this code, let me know if there is a
> better way, I wasn't aware of any issues with the minute data updates.
>   wkb = wkbfab.create_linestring(obj)
>   point = loads(wkb, hex=True).representative_point()
> https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250

It doesn't look like you have any location cache included when
processing updates, so that's unlikely to work.

Minutely updates don't have the full node location information.
If a way gets updated, you only get the new list of node ids.
If the nodes have not changed themselves, they are not available
with the update.

If you need location information, you need to keep a persistent
node cache in a file (idx=dense_file_cache,file.nodecache)
and use that in your updates as well. It needs to be updated
with the fresh node locations from the minutely change files
and it is used to fill the coordinates for the ways.

Once you have the node cache, you can get the geometries for
updates ways. This is still only half the truth. If a node in
a way is moved around, then this will naturally change the
geometry of the way, but the minutely change file will have
no indication that the way changed. Normally, these changes are
relatively small and for some applications it is good enough
to ignore them (Nominatim, the search engine, does so, for example).
If you need to catch that case, then you also need to keep a
persistent reverse index of which node is part of which way
and for each changed node, update the ways it belongs to.
There is currently no support for this in libosmium/pyosmium.
So you would need to implement this yourself somehow.

Kind regards

Sarah

> 
> Your query is correct, and you are right that (in theory) there shouldn't
> be any ways without the center point. But there has been a number of ways
> with only 1 point, causing a parsing error "need at least two points for
> linestring". I will need to add some special handling for that
> (suggestions?).
> 
> You can see the error by adding this line:
>OPTIONAL { ?osmId osmm:loc:error ?err . }
> The whole query --  http://tinyurl.com/ydf4qd62  (you can create short urls
> with a button on the left side)
> 
> On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:
> 
> > Hi,
> >
> > Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
> >
> > > * all ways now store "osmm:loc" with centroid coordinates, making it
> > > possible to crudely filter ways by location
> >
> > out of curiosity, can you say a few words on how your overall approach
> > to calculate centroids for ways? As we all know it's an endless pain to
> > get that information out of minutely diffs :)
> >
> > I have to say that I'm pretty much unfamiliar with SPARQL and just tried
> > the following query. My expectation was that I won't get any results,
> > making me wonder if my query has some issue?
> >
> > SELECT * WHERE {
> >   ?osmId osmm:type 'w' .
> >   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> > } LIMIT 100
> >
> >
> > BTW: A quick search on Github yielded the following:
> > https://github.com/nyurik/osm2rdf. Would that be the right place to look
> > for more details?
> >
> > Best,
> > mmd
> >
> >
> > --
> >
> >
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >

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


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

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Yuri Astrakhan]

For relations, I simply add "members" in addition to "tags".  The members
are stored as 3 different predicates:  "osmm:has", "osmm:has:_", and
"osm:has:..." (where the ... represents any "valid" label - same rules as
for the tag key).  The object (value) of the statement is a link to another
OSM object. Copying from wiki:
# this relation contains a way with blank label
  osmm:has osmway:2345 ;
# this relation contains a node with a non-ascii label
  osmm:has:_ osmnode:1234 ;
# this relation contains a relation labelled as "inner"
  osmm:has:inner osmrel:4567 ;

See
https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service#How_OSM_data_is_stored

At this point there is no "osmm:loc" stored for relations. I wonder if it
is possible to calculate it dynamically using the geo functions built into
Wikidata's engine (Blazegraph + customizations). If not, I might need to do
some relations postprocessing, as well as automatic updating.

On Mon, Aug 14, 2017 at 1:39 PM, François Lacombe  wrote:

> Hi
>
> 2017-08-14 11:18 GMT+02:00 mmd :
>
>> Hi,
>>
>> Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
>>
>> > * all ways now store "osmm:loc" with centroid coordinates, making it
>> > possible to crudely filter ways by location
>>
>> out of curiosity, can you say a few words on how your overall approach
>> to calculate centroids for ways? As we all know it's an endless pain to
>> get that information out of minutely diffs :)
>>
>
> Out of curiosity, can you explain how relations are processed also ?
> Is this relevant to look for a representative point for a relation or a
> more complex search have to be done for specific members (roles) ?
>
> I don't know Shapely enough to say if it can handle this standalone and it
> would be greate to elaborate a bit what is done from line 260 to 280 of
> osm2rdf.py :)
>
>
> All the best
>
> François
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[François Lacombe]

Hi

2017-08-14 11:18 GMT+02:00 mmd :

> Hi,
>
> Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
>
> > * all ways now store "osmm:loc" with centroid coordinates, making it
> > possible to crudely filter ways by location
>
> out of curiosity, can you say a few words on how your overall approach
> to calculate centroids for ways? As we all know it's an endless pain to
> get that information out of minutely diffs :)
>

Out of curiosity, can you explain how relations are processed also ?
Is this relevant to look for a representative point for a relation or a
more complex search have to be done for specific members (roles) ?

I don't know Shapely enough to say if it can handle this standalone and it
would be greate to elaborate a bit what is done from line 260 to 280 of
osm2rdf.py :)


All the best

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

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[Yuri Astrakhan]

mmd, the centroids are calculated with this code, let me know if there is a
better way, I wasn't aware of any issues with the minute data updates.
  wkb = wkbfab.create_linestring(obj)
  point = loads(wkb, hex=True).representative_point()
https://github.com/nyurik/osm2rdf/blob/master/osm2rdf.py#L250

Your query is correct, and you are right that (in theory) there shouldn't
be any ways without the center point. But there has been a number of ways
with only 1 point, causing a parsing error "need at least two points for
linestring". I will need to add some special handling for that
(suggestions?).

You can see the error by adding this line:
   OPTIONAL { ?osmId osmm:loc:error ?err . }
The whole query --  http://tinyurl.com/ydf4qd62  (you can create short urls
with a button on the left side)

On Mon, Aug 14, 2017 at 5:18 AM, mmd  wrote:

> Hi,
>
> Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
>
> > * all ways now store "osmm:loc" with centroid coordinates, making it
> > possible to crudely filter ways by location
>
> out of curiosity, can you say a few words on how your overall approach
> to calculate centroids for ways? As we all know it's an endless pain to
> get that information out of minutely diffs :)
>
> I have to say that I'm pretty much unfamiliar with SPARQL and just tried
> the following query. My expectation was that I won't get any results,
> making me wonder if my query has some issue?
>
> SELECT * WHERE {
>   ?osmId osmm:type 'w' .
>   FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
> } LIMIT 100
>
>
> BTW: A quick search on Github yielded the following:
> https://github.com/nyurik/osm2rdf. Would that be the right place to look
> for more details?
>
> Best,
> mmd
>
>
> --
>
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM Wikidata SPARQL service updated

[mmd]

Hi,

Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:

> * all ways now store "osmm:loc" with centroid coordinates, making it
> possible to crudely filter ways by location

out of curiosity, can you say a few words on how your overall approach
to calculate centroids for ways? As we all know it's an endless pain to
get that information out of minutely diffs :)

I have to say that I'm pretty much unfamiliar with SPARQL and just tried
the following query. My expectation was that I won't get any results,
making me wonder if my query has some issue?

SELECT * WHERE {
  ?osmId osmm:type 'w' .
  FILTER NOT EXISTS { ?osmId osmm:loc ?osmLoc }.
} LIMIT 100


BTW: A quick search on Github yielded the following:
https://github.com/nyurik/osm2rdf. Would that be the right place to look
for more details?

Best,
mmd


-- 





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