[OSM-legal-talk] Proposed "Metadata"-Guideline

[Tom Lee]

Certainly that's a related issue, but it's one with solutions.
OpenAddresses is not monolithic; its 1400+ individual datasources would
need to be evaluated individually and in concert with local mappers. In
some cases it might be appropriate to perform automated imports; in others
it might make sense to use a microtasking interface and/or to combine the
workflow with building-tracing tasks. In some cases the source data
includes footprints as well. And in others the data probably shouldn't be
imported at all.

It's not a trivial amount of work, but it's a project I and a number of
other people would be glad to dive into, if OSM was a better home for
geocoding.

On Tue, Oct 13, 2015 at 1:43 PM, Steve Coast <steve at asklater.com> wrote:

> Tom
>
> Isn’t the problem one of imports? The debate on importing 200M points
> would be entertaining.
>
> Steve
>
> On Oct 13, 2015, at 10:12 AM, Tom Lee <tlee at mapbox.com> wrote:
>
> > I think I agree with everything but this - I still don’t think it’s good
> enough. Of course, I also want it to be better - but that cogent argument
> thing you mentioned is missing either way.
>
> I and many others have been investing considerable energy into the
> OpenAddresses project because of ambiguity surround ODbL's implications for
> geocoding. OA is now over 200M address points collected from government
> sources under open licenses; OSM currently has 56M features with
> `addr:housenumber`.
>
> Obviously, not all of those 200M points belong in OSM. But many of them
> do. OpenAddresses does not have the toolchain or community needed to
> improve and maintain that data. Ultimately, those datasets should enter a
> collaborative space where they are accessible to and improvable by all. In
> the not-too-distant future, I suspect I will need to adjust a point when
> the local pizza place has their drone drop my order on the roof
> <http://media.salon.com/2015/03/Screen-Shot-2015-03-11-at-10.59.45-AM-1280x808.png>.
> I want to do that work once in OSM, not a hundred times in a hundred
> different closed geo databases.
>
> OSM is already good enough to make geocoding services *better* for many
> geography types and locations. The plausible mechanism by which it becomes
> *self-sufficient* and then *great* at geocoding is through network
> effects and concrete needs, not through individual pizza purchasers
> complying with the Terms of Service printed on the box containing their
> dinner.
>
> To me, this means making sure OSM-enabled geocoding services can be
> constructed alongside proprietary data; and that their results can be used
> by enough people to make the project's improvement matter to them.
>
>
>
>
>
> On Mon, Oct 12, 2015 at 7:15 PM, Simon Poole <simon at poole.ch> wrote:
>
>>
>>
>> Am 12.10.2015 um 23:43 schrieb Mr. Stace D Maples:
>>
>> ..
>> Neither of the projects was scrapped because we *couldn’t* use OSM for
>> the project, but because we couldn’t determine IF WE COULD use OSM for our
>> particular uses.
>>
>> ...
>>
>>
>> And you or your legal department approached the licensor of the data and
>> asked for an opinion on your use of the data?
>>
>>
>>
>>
>> _______________________________________________
>> legal-talk mailing list
>> legal-talk at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/legal-talk
>>
>>
> _______________________________________________
> legal-talk mailing list
> legal-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
>
> _______________________________________________
> legal-talk mailing list
> legal-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/legal-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20151013/06cf4c2b/attachment-0001.html>