Hi,
On Sat, Nov 21, 2020 at 07:09:45PM +, Eric H. Christensen via Tagging wrote:
> You cannot point to other area that may, in fact, be improperly mapped as an
> example when they are like that because locals have been shouted down for
> doing it correctly. The fact that this keeps coming ba
Given the number exposed here by Martin, and the fact that there is a few
established data consumers, I think that preserving the pump tag as it is now
and refine it with another tag would be a good idea indeed.
Yves
Le 22 novembre 2020 02:58:07 GMT+01:00, Martin Koppenhoefer
a écrit :
>
>
>s
[cross-posted to talk-us@ and tagging@, please choose your follow-ups wisely]
Brian M. Sperlongano wrote:
> It seems that we are increasingly doing things to simplify the
> model because certain tooling can't handle the real level of
> complexity that exists in the real world. I'm in favor of fix
Hi Martin, Yves
Usage is a good point, thank you.
Le dim. 22 nov. 2020 à 03:01, Martin Koppenhoefer
a écrit :
> this would deprecate around 20k pump values describing a pump type, plus
> 15k yes/no.
>
OSM counts 143k water_wells according to taginfo for man_made=water_well.
There are 21k pump
On 22/11/2020 11:24, Richard Fairhurst wrote:
[cross-posted to talk-us@ and tagging@, please choose your follow-ups
wisely]
If you go against the accepted principle of not X-posting on a
newsgroup, you've no entitlement to lecture how others respond.
Brian M. Sperlongano wrote:
> It seems
I recently found out about the Extremely long Amtrak route relations from
clay_c.
Your message is a bit confusing at first but I think you are proposing that
relations and super-relations should be used more-often to reduce the
complexity of processing data for data consumers?
In that case, I wou
> Dave F via Tagging hat am 22.11.2020 17:08
> geschrieben:
>
> [...] OSM-carto demanding boundaries on ways
???
I am smelling fake news here.
--
Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https:
Super relations could also solve problems like the Tongass National
Forest. By crafting a relation of relations, you still preserve the
ability to have one tagged super-object represent one complex thing in real
life, but with natural cut points so that any consumer can choose to deal
with in in m
I agree. I removed such duplicate tagging from my area some time ago, and
it has not affected anything.
I even went so far as to draft a proposal to change that recommendation.
https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/proposals/Boundary_relation_way_members
On Sun, Nov 22, 2020, 11:3
Nov 22, 2020, 17:08 by tagging@openstreetmap.org:
> Likewise we need to stop software developers from expectingcontributors
> to add data purely because they can't be bothered/notcompetent enough to
> write a few lines of code. (OSM-carto demandingboundaries on ways)
>
[citation n
I agree with Dave F.
It's a duplicate.
On Sat, Nov 21, 2020 at 7:43 PM Dave F via Tagging <
tagging@openstreetmap.org> wrote:
> To me, boardwalk describes the design & appearance rather than the surface
> construction: An elevated walkway.
> Although I do admit that's mostly influenced by The Dr
I'm surprised you think that as you were a contributor to the discussions:
https://github.com/gravitystorm/openstreetmap-carto/pull/3102
https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html
DaveF
On 22/11/2020 16:32, Christoph Hormann wrote:
Dave F via Tagging hat am
On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging <
tagging@openstreetmap.org> wrote:
> On 22/11/2020 11:24, Richard Fairhurst wrote:
>
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this
On 22/11/2020 18:12, Clay Smalley wrote:
On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging
mailto:tagging@openstreetmap.org>> wrote:
Contributing to the database (also *volunteers*) are expected to
map to a certain standard. There shouldn't be a reason to expect
develops not t
Am 22.11.2020 um 17:35 schrieb Brian M. Sperlongano:
..
I like the idea of an api limit, though we would need a strategy to
deal with existing large objects.
..
This is, "surprise", not a new topic. There are certain issues with the
semantics of relations which make this slightly more invo
Excuse me, what is the limitation here against tagging "Extremely long
Amtrak relations"? Some of those Amtrak services, while long, in my
knowledge are still far from the longest in the OSM database, like they're
shorter than the train route between Moscow to Pyongyang, which have been
tagged as a
Nov 22, 2020, 19:34 by tagging@openstreetmap.org:
>
>
> On 22/11/2020 18:12, Clay Smalley wrote:
>
>> On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging <>>
>> tagging@openstreetmap.org>> > wrote:
>>
>>>
>>>
>>> Contributing to the database (also *volunteers*) are
Nov 22, 2020, 19:00 by tagging@openstreetmap.org:
> I'm surprised you think that as you were a contributor to the discussions:
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/3102
>
This is a closed, not implemented PR. So it is not a case of
"OSM-carto demanding boundaries on ways
sent from a phone
> On 22. Nov 2020, at 18:47, Seth Deegan wrote:
>
> I agree with Dave F.
>
> It's a duplicate.
I also agree with Dave F., it is not a suitable surface value, nor is it a
duplicate of “surface= wood”
Cheers Martin
___
Tagging m
> Mateusz Konieczny via Tagging hat am 22.11.2020
> 20:49 geschrieben:
>
> > https://lists.openstreetmap.org/pipermail/tagging/2018-March/035347.html
> Yes, long time ago there was a problematic idea that was abandoned.
Exactly. It also shows how we in OSM traditionally make decisions about
As time goes on, we will encounter increasingly accurate and resolute
mechanisms for surveying things like coastlines and land cover. For
example, there are discussions about whether to use things like AI and
machine learning to produce such data. The demand for ways to deal with
larger objects w
Brian, as someone who worked on these national rail relations (and still does,
to some extent, though only around the edges), I agree with you that "very
large" relations (in Amtrak we say that one route is >2500 relations and meets
that standard of "very large") do exist. And, they are unwield
On Sun, Nov 22, 2020 at 8:04 PM Brian M. Sperlongano
wrote:
> Therefore, a holistic solution is needed for large objects. Setting an
> api limit is good because it gives consumers a guarantee about the
> worst-case object they might have to handle. However, it must also be
> combined with a rep
23 matches
Mail list logo
