Am 08.09.2019 um 20:37 schrieb Christoph Hormann: > On Sunday 08 September 2019, Simon Poole wrote: >> I think you are confusing potentially extractable information with >> actual data. For example satellite imagery may have a potentially >> high information content that could be with appropriate processing be >> turned in to data, but each image in itself is at most one datum. > I see - so you want to quantify by counting 'data objects' of some sort. > I assume for the OSM side you want to go with the quantification of one > OSM feature equals one countable object and a large lake multipolygon > for example can count a few thousand? > > You'd still loose by a huge margin in a map with contour line relief > rendering of course. > > And i would still hold the bet that i would be able to get the OSM > fraction of any map below 50 percent without too much effort. > >> Now waiting for the every image is a pixel database argument. > You are aware that most satellite image layers used in visualizations > are produced from hundreds of thousands or even millions of individual > images, assembled pretty much in the same way as a map rendering is > assembled from multiple features. It therefore seems your 'one datum' > concept is somewhat fragile.
I wrote "at most" one datum, I would argue that that an image is an image (even if it is a composite image) and not a datum. But in any case the guideline refers to the "visible map rendering". At least in conventional use of the term, aerial imagery is not a map, but if you so which we could surely add a definition for "map" that makes it clear that we are referring to the rendering of map vector data and similar and not image-like layers. Simon > > I see exactly one possible quantification of data fractions in a map > that could not be easily circumvented. That would be based on the > number of human work hours that went into producing the data. This is > a rule i could support: If more human work hours went into producing > the non-OSM source data used in a map than in the OSM data used > attribution that is hidden by default is acceptable. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
