Two illustrations based on data from Taginfo, have been added to the staleness wiki. They show very highly concentrated tag and key distributions.
https://wiki.openstreetmap.org/wiki/Rarely_verified_and_third-party_data_staleness_in_OpenStreetMap#OpenStreetMap_Key.2FTag_distribution_analysis While it doesn’t seem clear whether or not these highly concentrated distributions imply data staleness or quality, I decided to share the illustrations because the results seemed surprising: The total number of keys present on 57 or fewer tags in the OpenStreetMap database represent 80% of the 76,177 keys (60,952/76,177). 74,938 out of 76,177 keys are used on just 1% of all tags in the OpenStreetMap database. Just 42 keys out of 76,177 keys are present on 80% of all tags (1.7Bn/2.1Bn) in the OpenStreetMap database. Best regards, Stuart On Tue, 7 Apr 2020 at 08:09, European Water Project < europeanwaterproj...@gmail.com> wrote: > Dear Martin, > > Yes, using external tables unioned to objects by opaque keys is not a very > KISS solution. A more KISS solution would be to keep tag meta data close to > or even better within the element itself. > > Assuming all tag values are stored in zero based arrays, could we not add > a 2 byte last updated/creation date meta data value to the [-1] index. The > overhead would be minimal, the overall OSM data structure would not have to > be modified. > > Best regards, > > Stuart > > On Tue, 7 Apr 2020 at 01:30, Martin Koppenhoefer <dieterdre...@gmail.com> > wrote: > >> >> >> sent from a phone >> >> On 6. Apr 2020, at 16:51, Paul Allen <pla16...@gmail.com> wrote: >> >> or use https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID >> >> >> I didn't even know that existed. I'm not sure I trust such IDs to survive >> intensive editing by newbies who can delete an object then add it >> with quite different tags. >> >> >> >> these IDs are defined through their significant properties, if these get >> “messed up” you may hope that someone else will fix it sooner or later. >> >> Compared to this, an ID_mySpecial_App=123 tag has much more potential >> for breakage, because following editors don’t know what it refers to (e.g. >> the physical place or the business/service?), and often don’t know how to >> deal with it when some properties have changed, or when they split them: >> keep it on all parts, some parts or remove it? To solve this you’d have to >> know what mySpecialApp does and how it uses the IDs. >> >> And we’d end up with a lot of different opaque foreign keys cluttering up >> the same objects, in some cases, even if we required the linked db to be >> free and open. >> On the other hand there are already people adding references to >> proprietary databases, e.g. 80000 facebook urls, 2000 google ids, 500 >> foursquare. The trick is to offer message relaying and use a contact: tag >> ;-) >> >> Cheers Martin >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
