PS: an extension syntax has the advantage of not breaking downstream consumers that are relying on maximum 255 char strings, which is probably a valid concern. A max length change should probably wait in any case till there are other data model changes (aka API 0.7 :-)) to minimize the impact.
Am 12.10.2018 um 01:27 schrieb Simon Poole: > We have a number of keys for which the values can easily exceed 255 > chars besides opening_hours, lane destinations and conditional > restrictions are good candidates. Not to mention changeset tags. With > other words it is a general problem which should be tackled with a > general solution. > > One would be to extend at least the available space in the database > for tag values, however that is a significant amount of work (see > https://github.com/openstreetmap/openstreetmap-website/issues/1593) > and I suspect it is unlikely to find support. > > The other way to address this would be to provide a general value > extension syntax that editors and consumers could support for example > say /key-/ext/-nnn /The exact semantics would need to be determined > (how to split and join long values) and the key syntax needs to be > chosen to minimize possible conflicts. > > Simon > > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
