Re: [OSM-talk] Draft Geocoding Guideline
Hi all - A few thoughts on the comments. Speaking entirely on my own behalf here, I have not gotten feedback on this yet from the rest of the LWG. [from Christoph] But if you aggregate such results they can become subject to the ODbL. . . > The difference is that indirect results are significantly *less > substantial* than direct results because by interpolating you lose a lot of > substance. Spelling this out makes sense to me but the formulation cited > above seems to be misleading and confusing. [from Martin] Rather than "contain no osm data" this could be seen as "contain only > transformations of osm data, no raw osm data". I think I see the confusion here now. What if we tweaked this language to something like the following? *CURRENT DRAFT: Individual Geocoding Results are insubstantial database extracts if they are based on a Direct Hit. Individual Geocoding Results that are based on an Indirect Hit contain no OSM data and so are free of any obligations under the ODbL.* *PROPOSED REVISION: Individual Geocoding Results are insubstantial database extracts: Individual Geocoding Results that are based on a Direct Hit contain an insubstantial amount of raw OSM data; Individual Geocoding Results that are based on an Indirect Hit contain no raw OSM data at all and only transformations of or inferences from OSM data.* [from Martin] E.g. my algorithm could take a list of all streets, query all house numbers > from 1 to x (until it doesn't find any more hits for a sequence of > numbers), but not the numbers 3 and 4 . . . The hypothetical sounds like a systematic attempt to extract "substantially all" addresses. It also does sound to me like the intent would likely be to create a general purpose geodatabase from OSM (for example use of the results again as a geocoder). So share-alike would apply: “A collection of Geocoding Results will be considered a systematic attempt to aggregate data if it is used as a general purpose geodatabase, regardless of how the original aggregation was accomplished.” Without attributing to osm The attribution piece of this is indeed somewhat tricky. We wrote a fairly detailed explanation of our reasoning in the FAQ section of the wiki. To be clear: anyone running a geocoder based on OSM would need to attribute OSM. Yes, individual geocoding results are not substantial, but geocoding is > typically executed many times (i.e. systematically), and it is the sum of > the geocoding results that makes the extract substantial. Yes agreed - a collection of Geocoding Results can have enough data to be a Substantial Extract of an OSM Database and a Derivative Database. This applies to both Direct and Indirect Hits. Hopefully the proposed new wording above would help clarify this. Thanks again for the feedback. -Michael > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Draft Geocoding Guideline
Thank you to everyone who looked over the draft Geocoding Guideline that
Simon circulated last month. The comments were very helpful.
The license working group (LWG) discussed the feedback at our last meeting,
and we've updated the draft to incorporate the following suggestions:
- Expanding the "substantial extract" limitation to cover ref tags, house
numbers, and similar tags
- Making the attribution obligations more specific by referencing Section
4.3 of the ODbL
These changes are now reflected in the wiki: https://wiki.openstreetmap.
org/wiki/Draft_Geocoding_Guideline
We also considered other suggestions:
- There was a suggestion to remove the definitions of Direct Hit and
Indirect Hit. While we agree that the underlying rule is the same for both
types of results, we do believe there is a practical difference: more
Indirect Hits (typically interpolated results) will generally be necessary
to infer OSM data than Direct Hits. We think spelling this out will help
future users understand and apply the guideline.
- There were a couple suggestions to further narrow the substantial
extract limitation ("all or substantially all" -> "majority",
sub-city-level geographic limitation). We think the combination of the
current geographic, tag, and proportion limitations are sufficient to deter
levels of abuse that would meaningfully compete with or pull contributions
from OSM, while the original reasons for the approach in the draft --
clarifying and facilitating typical, non-problematic geocoding use of OSM
-- remain. There was a related question about comparison of the draft to
the Substantial Guideline: in contrast to the Substantial Guideline, the
draft Geocoding Guideline rule applies only where the data in geocoding
results is limited to specific tags and excludes even results that are
small subsets of features within a geographic area (i.e. any group of
primary features). In contrast, the Substantial Guideline addresses when it
would be acceptable to extract feature data in its entirety, or all the
features in a geographic area. So it’s natural that the geographic
restrictions are different. We discuss our thinking on this a bit in the
FAQ on the wiki as well.
Again, we've greatly appreciated the comments to date. We'll be running
this second consultation phase on the revised draft through the next two
weeks.
Thanks to all the LWG members who've contributed thoughts and comments, and
to Simon for his leadership of the working group as always.
-Michael
On Mon, Jun 5, 2017 at 6:04 AM, Martin Koppenhoefer
wrote:
>
> 2017-06-02 10:32 GMT+02:00 Christoph Hormann :
>
>> > Individual Geocoding Results that are based on an Indirect Hit
>> > contain no OSM data and so are free of any obligations under the
>> > ODbL
>>
>>
>> IMO it would make sense to remove this distinction because the guideline
>> makes no significant difference between these two cases. And even if
>> indirect hits contain no OSM data they are clearly derived from OSM
>> data.
>>
>
>
> +1
>
> More questions concerning:
>
>
> "A collection of Geocoding Results is not a substantial extract of the OSM
> database provided:
> ...
> 2. the collection is not a systematic attempt to aggregate all or
> substantially all Primary Features of a given type (as defined in the
> Collective Database Guideline) within a geographic area city-sized or
> larger."
>
>
>
> 2.1 "the collection is not a systematic attempt to aggregate all or
> substantially all Primary Features of a given type"
>
> what if it is not about Primary Features but certain properties (e.g.
> query in a grid for many points for the language of the name tag of nearby
> features and then construct language areas by creating hulls around points
> with the same language. With this guideline it would not fall under ODbL,
> but IMHO would clearly by a derivative database.
>
>
> 2.2 "all or substantially all Primary Features"
>
> If I throw away an arbitrary 5-10% of the results of all places in the
> world, it would be ok to store name and coordinates in a db and use it
> without any license obligation? Isn't "all or substantially all" quite
> exclusive? Why not for example "a majority"?
>
>
> 2.3 "geographic area city-sized or larger. "
> How big is a "city", which definition of "city" is used? If I use the
> method to get coordinates for all addresses of Manhattan, this would
> clearly be less than "city size"? Or 2 thirds of Rome?
>
> What is the reason we don't use the introduced "substantial" criteria as
> defined here, for geocoding as well:
> https://wiki.osmfoundation.org/wiki/Licence/Community_
> Guidelines/Substantial_-_Guideline
>
> In particular "The features relating to an area of up to 1,000 inhabitants
> which can be a small densely populated area such as a European village or
> can be a large sparsely-populated area for example a section of the
> Australian bush with few Features." which is way smaller than "city sized".
>
> Cheers,
> Martin
>
>
>
>
>
[OSM-talk] RSS Feed for OSM API Changesets
Hello, I'm proud to announce my first version of a script to generate RSS 2.0 newsfeeds out of the new OSM changesets API. Detailed information could be found on my blog: http://www.steffenvogel.de/2009/05/06/osm-changesets-als-rss-feed/ greeting from Germany Steffen -- Steffen Vogel Karlstraße 5 64347 Griesheim Tel: +49 (6155) 78877 Handy: +49 (176) 96978528 EMail: i...@steffenvogel.de Web: http://www.steffenvogel.de ICQ: 176824121 MSN: i...@steffenvogel.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Link to the map legend
internationalization ^^ i + 18 characters + n = internationalization Am Donnerstag, den 01.01.2009, 23:03 + schrieb Gregory: > > Btw. are there any attempts to i18n the main OSM page? > > i18n what? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Am Donnerstag, den 27.11.2008, 18:30 + schrieb Christoph Böhme: > Hi! > > Florian Lohoff <[EMAIL PROTECTED]> schrieb: > > I'd vote for making the OSB as simple as possible - as soon as you > > require a login or filling in some drop downs we'll loose Aunt Tilly > > with her good local knowledge. > > I am completely with you here. However, while Aunt Tilly wants a > no-frills interface mappers who are dealing with bugs need a bit more > functionality. There might be also people willing and able to provide > more detailed bug reports. They should have the option to do so. > IMO, the problem is to put these three things together. > > I think, it is quite clear that we need an Aunt Tilly-interface to the > bugtracker with the following features: > > - no registration required Unfortunatly Bugzilla don't provides this feature. But I already found a solution: I've created a guest user. Any bug reports thru the slippy map will be added as reports from the guest user. > - only a single text field to describe the error No problem. Default values for other fields will be set. > - optional email address if the reporter wishes to be contacted There is a way to add people to the CC header of a mail. I have to prove that this is also possible for nonregistred persons. > > So, basically what openstreetbugs is now. Though, I see no point > why things behind this interface could be a bit more advanced. Since > only mappers will use them. I also see no reason why the Aunt > Tilly-interface should not contain a link saying advanced which shows > some more options (like classification and so on). > > Christoph > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for a map-bug tracker (Openstreetbugs)
Am Donnerstag, den 27.11.2008, 15:16 + schrieb Christoph Böhme: > Hi, > > after the two latest discussions on the list I sat down and put > together a little proposal for an improved map-bug tracker: > > http://wiki.openstreetmap.org/wiki/Bugtracker_proposal > Hey great work! I already modified the software-bug classifications, statuses of Bugzilla, due to the needs of a MapBugTracker. Do we have some perl programmers around here? I could need some help to adapt the slippy map scripts to Bugzilla. It's not as hard as it might sound. Bugzilla owns a XML-RPC backend which we can use... greetings Steffen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Unification of OpenStreetBugs an Trac
As a user and mapper of OpenStreetMap, I often use OpenStreetBugs. Unfortunatly this project is quity poor in features like: - email notification - duplicate handling - user handling - attachements (pictures, links, etc...) - search - filters - reports, charts & statistics etc. Bug trackers like Bugzilla can cope with these requirements a lot better. What do you think about a migration of OpenStreetBugs to Bugzilla? Nevertheless OpenStreetBugs has a also some pros: - simplicity - integration in a slippy map and JOSM But I think it would'nt be hard to implement these pros to Bugzilla. I've already put a installation of Bugzilla to my Server (http://bugs.griesm.de) and I've done some testing around. Bugzilla is coded in perl. I've some basic perl skills. But I'm afraid thats not enough. Perhaps we can some more expierenced perl codes here in the community? A migration of the other bug trackers (http://trac.openstreetmap.org) to Bugzilla would ensure that we have projectwide unique Bug IDs. Small an new projects without a bug tracker could use this installation. I think this would lead us to a faster developement cyclus... It's just imagination.. What do you think about it? greetings from Germany, Steffen Vogel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
