On 2017.11.10. 00:11, Sean Lindsey wrote:
> It seems that it's going to be hard to come up with a mass import
> solution that every one can agree on. I would suggest that you take
> name, address, phone number, website and category then try and
> re-geocode the data, but it seems there is opposition to this method as
> well.
> 
> Another approach - as a way of keeping OSM and this data separate - is
> having this POI data be a "secondary resource" that OSM users could "opt
> in" to adding into their mapping set, but not be inherently owned or in
> OSM's primary data set. For example, by loading up an OSM database you
> could be linked to us or someone who creates a derivative of our data
> suitable for importing into OSM maps. Thereby OSM does not feel
> responsible for this resource but it still becomes available for people
> to import and use via us or someone else. In this case we would want to
> work with someone in order to create an OSM import-friendly version of
> this data. We have a ton of indicators that tell us the quality and
> freshness of this data and potentially we can rework in into something
> more usable.

as opposed to some other data (public transportation timetables and
similar), this information belongs in osm - the concern is not about it
being there, the concern is about licensing and accuracy, both being
discussed and clarified.
accuracy issue can be handled by a layer that looks for features in this
dataset that cannot be matched to existing osm features. sort of map
notes, although flooding notes with this might not be feasible.
osm community response, after a survey, could be to add the entity, add
it with corrections (location etc) or reject it as not existing on the
ground - it might be useful to get a feedback loop for those.

feedback amount will vary a lot. i'd expect smaller towns and the like
not to get much feedback at all. suggesting a layer like this to be
used. any pois without any feedback in 6 months to be imported (split in
smaller sections and all other usual precautions).
this would not be a blanked import and would be expected to be "better
than before".

> Thoughts?
> 
> On Thu, Nov 9, 2017 at 1:09 AM, Rory McCann <r...@technomancy.org
> <mailto:r...@technomancy.org>> wrote:
> 
>     Hi Sean,
> 
>     On 09/11/17 07:14, Sean Lindsey wrote:
>     > Thanks for all the feedback, we have put together some blogs to help
>     > people figure out how to play with the data, to give people an idea of
>     > what it is and how it was put together.
>     >
>     > https://blog.cybo.com/
> 
>     So that website says:
> 
>         OmniPlaces is formed from billions of records (literally), from
>         tens of thousands of sources (literally)
> 
> 
>     Trying to figure out the licence for tens of thousands of datasets is
>     practically impossible.... Licence issues are often a problem with
>     imports, and I think this could be a show-stopper for this.
> 
>     On 09/11/17 05:54, Jo wrote:
> 
>         If the addresses are in the data as well, we don't really need
>         to use
>         the lat/lon coordinates.
> 
> 
>     Not necessarily, depends where the addresses came from. If you had
>     lots of lat/longs, and geocoded the, and threw away the lat/longs
>     then you don't have a clean dataset.
> 
>     -- 
>     Rory
> 
> 
> 
>     _______________________________________________
>     Imports mailing list
>     impo...@openstreetmap.org <mailto:impo...@openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/imports
>     <https://lists.openstreetmap.org/listinfo/imports>
> 
> 
> 
> 
> -- 
> Sean Lindsey
> Cybo Company
> LinkedIn <https://www.linkedin.com/in/sean-lindsey/>
> 541-912-2505 <tel:(541)%20912-2505>
> 
> 
> _______________________________________________
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
> 


-- 
 Rihards

_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Reply via email to