Remove non-prefixed versions of 'contact:' scheme

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Marc M.
Le 11.05.20 à 11:29, Shawn K. Quinn a écrit :
> In fact, I'm not sure how useful it is for us to tag phone numbers on
> phoneboxes at all. Does anyone actually use this data for something useful?

it look like a ref, and a ref is useful to link 2 databases,
including if we put it in the ref key :)

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Paul Allen
In reply to this post by s8evq-2
On Mon, 11 May 2020 at 10:58, s8evq <[hidden email]> wrote:
Hi Paul,

On Mon, 11 May 2020 02:10:12 +0100, Paul Allen <[hidden email]> wrote:
> I find the whole contact: namespace to be ill-conceived.  But fine, if
> you want it then use it.  Just please stop suggesting that we
> deprecate website=* and phone=*.

What's you counter argument to the people suggesting that contact:* makes it easier for data consumers to gather all contact info in one go, instead of hard coding all the possible keys. What if next year a new way of contacting comes up?

Since you ask...

What purpose does that actually serve?

For mappers, no purpose.  They use the editor preset and get phone=* or
contact:phone=* depending upon what the author of the editor thinks is the right
way to do it.  No purpose for mappers who enter raw tags either - it's easy
enough to create a wiki page for "Contact Tags" and list phone, website,
fax, telepathy, etc.  Maybe, just maybe, for newbies who aren't sure of
what contact tags are available and want to be able to type "contact"
into the editor and get a list of possibilities, but some editors do
searches of brief tag descriptions that would achieve the same thing.  But
I'd argue most mappers operate on "I have a phone number for this POI,
how do I tag it?" rather than "What contact methods are available for
POIs, when I know that I'll check if this POI has any of them."

For users, little purpose.  They use the query tool in standard carto (or similar
tool in other cartos) and get a list of tags.  If a POI had dozens of tags then
grouping the contact tags in one place might be slightly helpful, but in most
cases not.

For carto, no purpose.  They ignore tags unless somebody has specifically
put in handling code for them.  They don't (and probably won't) render POIs
with some form of contact tag any differently, so it doesn't matter if they
don't code for phone=* or don't code for contact:phone=* because not
coding to handle a tag requires no effort.

For data queries, maybe a purpose.  But first you have to convince me that
anybody would have reason to perform such a query.  Bring up overpass-turbo,
move the map to a particular area, and find all the POIs which have any method
of contacting them.  Why would anybody want to do this?  And if you can
come up with a reason, how often is this likely to happen?  Often enough
that it's worth all the hassle of contact:*=* so that somebody can build a
query on "contact:*=*" rather than "phone=* and website=* and fax=*
and whatever=*"?

The only purpose I've seen anybody mention for contact:phone is
for a phone number to contact a car park's operator.  And even that
doesn't really seem justified.  It's a phone number for a POI.  The
phone isn't physically at the POI but it's the number you dial to talk
to the operator of the POI.  I don't see any reason to make a
distinction.

I've yet to see anybody explain what a phone number is for other than to
contact somebody.  There are fax numbers, but they would be better
handled by fax=*.  As Gertrude Stein didn't say, a phone number is
a phone number is a phone number.

The contact: namespace seems to be taxonomic hierarchy for taxonomic
hierarchy's sake.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Marc M.
Le 11.05.20 à 14:42, Paul Allen a écrit :
> On Mon, 11 May 2020 at 10:58, s8evq wrote:
>     What's you counter argument to the people suggesting that contact:*
>     makes it easier for data consumers to gather all contact info in one
>     go, instead of hard coding all the possible keys. What if next year
>     a new way of contacting comes up?
>
> For mappers, no purpose.  They use the editor preset

your answer is precisely the *problem* in the question
every new contact need a new preset in stead of query taginfo
and show top X contact:*
same problem for the user of the data. if somebody wants to display
all the details of a shop, he has to make a hardcoded list of phone
website... instead of being able to display all the contacts:* that
the osm contributor has filled in.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Paul Allen
In reply to this post by Cj Malone
On Mon, 11 May 2020 at 02:48, Cj Malone <[hidden email]> wrote:
On Mon, 2020-05-11 at 02:10 +0100, Paul Allen wrote:
> And yet you, and others, keep saying it.  "Deprecate" means "express
> disapproval of."  In the context of OSM, it means "phase out."  That
> is,
> eradicate with the passage of time.  It may not be what you mean, but
> it's what you keep saying.

Any yet what I described was a phase out with 3 steps.

"Phase out": "to discontinue the practice, production, or use of by phases.
intransitive verb. : to stop production or operation by phases." 

So you explicitly state that you do not wish to get rid of the phone tag yet
continue to find different ways of implicilty saying that you wish to get
rid of the phone tag.  Is English not your first language?

I thought this mailing list was the official avenue for disusing,
changing and adding tags in OSM. I didn't realise you had to get the
editor permission.

Unless you get editor buy-in then your shiny new tag won't get used
by many people because it's not offered as an editor preset.  Because
it doesn't get used much, authors of editors will say they're not
including it as a preset because it's not popular.  You may not like
that.  I certainly don't like that.  But it's how it is.

> Oh, and there's all the legacy usage you have to clean up, except
> we don't like automated edits.  But without cleaning it up, you make
> database queries more complex.

I don't have any arguments against automated edits, bulk edits, machine
assisted edits. In any dataset they are needed, especially one this
massive. But it's not a fight I have the effort to fight right now.

Very wise.  Because you have to have very, very strong justification for
automated edits in OSM.  The most fundamental precondition is that
ALL a=b change to x=y.  And even if you satisfy that precondition,
it probably won't be permitted.  And we already know you don't
satisfy that precondition because the phone number for a phone
box is not a contact phone number and various websites are
not contact pages.

> I am far from convinced that a contact phone number is not a phone
> number.
> If I see a phone=* on a phone box I know it is not a contact number.
> If
> I see a phone=* on a business I know it's a contact phone number for
> the business.  What extra utility does having contact:phone provide?
> And is it worth the hassle of manually editing all the existing tags
> to
> fix?

That's just one edge case with the phone tag. Another one being phone
on parking. Is that the number you call to pay, or is it the number you
call to contact the operator because there is something wrong.

So it's a phone number you call if you want to talk to somebody a POI.
That's an edge case how?

I believe there are more edge cases we still aren't thinking of, and if
we aren't the user agents defiantly aren't.

I don't think you've found any edge cases yet.  I don't think there are any
edge cases unless you can find one where a contact phone number isn't
a phone number.

Amusingly, the more arguments you put forward the more convinced I am
that contact:* is a horrible idea without merit.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Paul Allen
In reply to this post by Marc M.
On Mon, 11 May 2020 at 13:51, Marc M. <[hidden email]> wrote:
Le 11.05.20 à 14:42, Paul Allen a écrit :
> On Mon, 11 May 2020 at 10:58, s8evq wrote:
>     What's you counter argument to the people suggesting that contact:*
>     makes it easier for data consumers to gather all contact info in one
>     go, instead of hard coding all the possible keys. What if next year
>     a new way of contacting comes up?
>
> For mappers, no purpose.  They use the editor preset

your answer is precisely the *problem* in the question
every new contact need a new preset in stead of query taginfo
and show top X contact:*

Good point.  And, since we have hundreds of new ways of tagging contacts
appearing every day, very much needed.  Oh, we don't have new ways of
tagging contacts appearing every day.  Or even every month.  On average,
maybe once a year (if I'm being generous).  I'm not entirely convinced
this is a problem worth solving.

same problem for the user of the data. if somebody wants to display
all the details of a shop, he has to make a hardcoded list of phone
website... instead of being able to display all the contacts:* that
the osm contributor has filled in.

Good point.  I can't count all the times I've wanted all the contact details
of a POI but NONE of the other details like the name, the address, what
type of POI it is, etc.  Well, actually, I can.  Zero.  OTOH, there are a
lot of times I've wanted to know more about a POI but not been
interested in the contact details.

But even if you're correct, why are the results of the query tool in
standard carto unsuited to your needs?  Are you going to propose
changes to the tool so that, if the user wishes, it returns only the
contact details and no other information about the POI?

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Tagging mailing list
In reply to this post by Cj Malone



May 11, 2020, 03:47 by [hidden email]:
On Mon, 2020-05-11 at 02:10 +0100, Paul Allen wrote:
And yet you, and others, keep saying it. "Deprecate" means "express
disapproval of." In the context of OSM, it means "phase out." That
is,
eradicate with the passage of time. It may not be what you mean, but
it's what you keep saying.

Any yet what I described was a phase out with 3 steps.
"phase out with 3 steps",
"deprecate".
"get rid of",
"eliminate",
"gradually deprecating"

all mean that the plan is to eliminate the tag.

They subtly differ in how this elimination would
exactly work, but all describe process of
removing tag from use.

Number of steps, length of process is not changing that.

It is perfectly fine to deprecate/eliminate tags that are
harmful, I started or helped this process with numerous ones.

But trying to eliminate tag and avoiding calling it
deprecation/elimination is silly.

I would also advocate to focus on parts of tagging that
are without known long-standing gridlock.

Like contact:phone vs phone.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Tagging mailing list
In reply to this post by Cj Malone



May 11, 2020, 15:04 by [hidden email]:
I would also advocate to focus on parts of tagging that
are without known long-standing gridlock.

Like contact:phone vs phone.
To clarify: I advocate avoiding known messes like
phone vs contact:phone - this one will not be ever
resolved and that it is OK.

There are many open tagging issues (or simply things to map)
where attention is more useful.

-- signed, person who is probably spending too much
time on tagfidling anyway.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Tom Pfeifer
In reply to this post by Paul Allen
On 11.05.2020 03:10, Paul Allen wrote:

> I'm far from convinced that contact:website is useful.  It's certainly
> semantically wrong.  It's a contact;webpage not a contact:website
> (there are maybe a handful of exceptions to that).  Why do you think
> the user is more likely to require the webpage giving contact details
> rather than the home page of the web site?  I'd expect users are
> more likely to want more information on what a POI is than to
> want to find out how to contact it.
>
> I find the whole contact: namespace to be ill-conceived.  But fine, if
> you want it then use it.  Just please stop suggesting that we
> deprecate website=* and phone=*.

Indeed the main reason why my preference is not to use the contact:* scheme
is that its proponents did not limit the scheme to true means of contacting,
but tried to press everything into it that was not up in the trees when counting
to three.

The most prominent example is website, where only a page with a message form would
be clearly in this category. However what is more recommended to be mapped is the
basic homepage of a POI, because it is least likely to be changed in website relaunches.

The main purpose for me to read a website is to gain information about the object
and not to contact it.

In countries where an imprint is not mandatory, websites often do not even provide contact
details at all.

There are many more examples on the contact:* wiki page that are pure methods of dissemination
and not of contact, such as contact:youtube or even contact:flickr

How is contact:webcam supposed to fit into the scheme?

In contrast, postal addresses are a very typical means of contact, I can send a letter
there. So consequently, we would have to to move the "addr:*" scheme into "contact:addr:*",
which would make the scheme even more stilted.

I guess that contact:[phone|fax|email], and nothing more, could have won easily if the
scheme had not tried to include all the other stuff.

tom

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Graeme Fitzpatrick
In reply to this post by s8evq-2



On Mon, 11 May 2020 at 19:30, Shawn K. Quinn <[hidden email]> wrote:

In fact, I'm not sure how useful it is for us to tag phone numbers on
phoneboxes at all. Does anyone actually use this data for something useful?

Your local drug-dealers so people can ring them at the phone box? :-)

On Mon, 11 May 2020 at 20:18, s8evq <[hidden email]> wrote:
Do we have a lot of keys with double meaning, where you need to look at the which keys are also on the object to figure out the true meaning?

=taxi & =motorcycle_taxi? :-)

Thanks

Graeme


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Richard Fairhurst
I love the fact that we are now 50 messages into discussing, for the second
time, a change that would be made ostensibly for the benefit of data
consumers, and yet no one has asked any actual data consumers.

https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Philip Barnes
In reply to this post by Shawn K. Quinn

On 11/05/2020 10:29, Shawn K. Quinn wrote:
On 5/10/20 7:36 PM, Cj Malone wrote:
I think I stand by that quote, but I'm happy to discus it. I'm not
arguing that over night we should stop people using the phone tag.
Currently phone has at least 2 uses. A contact number and an incoming
number for a phone box. We should split these out. If we are left with
totally_new_tag_for_phoneboxes and phone, where
totally_new_tag_for_phoneboxes is defined as incoming phone number and
phone is defined as the contact number. I'm OK with that too, it's the
definitions that really matter.
Why should we split these out?

In fact, I'm not sure how useful it is for us to tag phone numbers on
phoneboxes at all. Does anyone actually use this data for something useful?

This is OSM, people can map anything that is verifiable.

I do map phone numbers of phoneboxes and can see various uses for this data.

The number of the phonebox in the village where my grandmother lived is still ingrained on my memory, we used to phone her at the phonebox at the same time every Sunday, being able to find out the number to call someone without visiting first is useful.

Taxi firms could find this useful to locate a customer who is unsure of their location.

I used to let my parents know I was ready to be picked up by letting the phone at home ring twice, I had to be at a specific place for that to work. But being able to look up the location of the phonebox would have meant I could be at any phonebox.

I am sure others will see other applications.

Phil (trigpoint)



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Quality and the Openstreetmap value chain

Jean-Marc Liotier
In reply to this post by Richard Fairhurst
On 5/12/20 11:42 AM, Richard Fairhurst wrote:
> I love the fact that we are now 50 messages into discussing, for the second
> time, a change that would be made ostensibly for the benefit of data
> consumers, and yet no one has asked any actual data consumers.

Yes. Users are the ultimate measure of quality, yet they are most often
absent from our discussions. Our history explains why: in the beginning,
we had a blank map, which we set upon filling with whatever we could, to
get the stone soup started. There were no consumers at all - so
naturally our universe was supply-side entirely: the availability of
data inspired usage, which came second. Nowadays, Openstreetmap is used
- let's take advantage of that to improve ! Looking at the world and
thinking about how we should model it should be done with an
understanding of how users want it. This is difficult when we have few
users around and very little feedback from downstream. So, if one has
opportunities to bring that to our knowledge, please do: it is valuable
information to the Openstreetmap project, information without which we
cannot allocate our efforts optimally.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Valor Naram
In reply to this post by Richard Fairhurst
Hey,

I am a "data customer", see https://babykarte.OpenStreetMap.de . That's why I initiated this discussion because this is important for me. But mappers are not listening to data customers and think they know how a database works (only few of them know that and those come from a technical field).

~ Sören Reinecke alias Valor Naram


-------- Original Message --------
Subject: Re: [Tagging] Remove non-prefixed versions of 'contact:' scheme
From: Richard Fairhurst
To: [hidden email]
CC:


I love the fact that we are now 50 messages into discussing, for the second
time, a change that would be made ostensibly for the benefit of data
consumers, and yet no one has asked any actual data consumers.

https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Paul Allen


On Tue, 12 May 2020 at 11:43, Sören alias Valor Naram <[hidden email]> wrote:
Hey,

I am a "data customer", see https://babykarte.OpenStreetMap.de . That's why I initiated this discussion because this is important for me. But mappers are not listening to data customers

Why do you think that other mappers are not data consumers?
 
and think they know how a database works (only few of them know that and those come from a technical field).

Why do you think they do not know these things?  And why do you think it
relevant?  Do you perhaps think that namespacing involves the creation
of a table for the namespace and that Codd's relational model applies to
namespaces?

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Remove non-prefixed versions of 'contact:' scheme

Colin Smale

On 2020-05-12 12:58, Paul Allen wrote:

On Tue, 12 May 2020 at 11:43, Sören alias Valor Naram <[hidden email]> wrote:
Hey,

I am a "data customer", see https://babykarte.OpenStreetMap.de . That's why I initiated this discussion because this is important for me. But mappers are not listening to data customers
 
Why do you think that other mappers are not data consumers?
and think they know how a database works (only few of them know that and those come from a technical field).
 
Why do you think they do not know these things?  And why do you think it
relevant?  Do you perhaps think that namespacing involves the creation
of a table for the namespace and that Codd's relational model applies to
namespaces?
 
Can someone come up with a metamodel description of the use of namespacing? It would be interesting to apply it to the current set of tags including a ":" character.
 
 

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Quality and the Openstreetmap value chain

Graeme Fitzpatrick
In reply to this post by Jean-Marc Liotier



On Tue, 12 May 2020 at 20:36, Jean-Marc Liotier <[hidden email]> wrote:
On 5/12/20 11:42 AM, Richard Fairhurst wrote:
Yes. Users are the ultimate measure of quality, yet they are most often
absent from our discussions.

From comments on the "contact point" thread

On Tue, 12 May 2020 at 20:43, Sören alias Valor Naram <[hidden email]> wrote:

I am a "data customer" ... But mappers are not listening to data customers

I'd really like somebody to come up with simple definitions of

mappers,

data consumers / customers,

users?
 
OK, I map, & I then also "use" OSMand for navigation purposes, so what am I?

Our history explains why: in the beginning, we had a blank map, which we set upon filling with whatever we could

Perhaps unfortunately, this was filled with a British / Western European / American view that because it's like this "here", the rest of the World must be the same, so must follow along with our set rules.

Looking at the world and thinking about how we should model it should be done with an understanding of how users want it.

Agree entirely, but as we have seen a few times in recent weeks. just because "this" definition doesn't apply in UK, EU / USA, there's no reason to wipe it from the map entirely, because it very well could, & does, apply perfectly  in other parts of the World.

This is difficult when we have few users around and very little feedback from downstream. So, if one has
opportunities to bring that to our knowledge, please do:

I, & others, have done so a few times, to basically be told sorry, that's not how it works in OSM - these are the rules & you have to follow them.

One in particular, roads in remote areas - yes, it's a dirt road, connecting very small centres of population / remote "farms" (if it's still a "farm" when it's bigger in area than some countries ) only, so it "can't" be important, so it doesn't appear on OSM till you zoom right in, but it's also the only "main" road for 1000 k's in any direction, so you would think that it should be shown at high level zoom?

Same, same with the (OSM) villages / hamlets / remote dwellings that this road serves. A single building out in the middle of nowhere, in the OSM universe, is too small & insignificant to be noticed, but that pub, with attached service (gas) station, general store & camping ground, is also the major point of civilisation for that 1000 k's!, so how important is it in real life to those people who are travelling through that area? Extremely!

Thanks

Graeme


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Quality and the Openstreetmap value chain

Tagging mailing list



May 13, 2020, 00:18 by [hidden email]:
One in particular, roads in remote areas - yes, it's a dirt road, connecting very small centres of population / remote "farms" (if it's still a "farm" when it's bigger in area than some countries ) only, so it "can't" be important
Dirt road may be highway=trunk if it is the main road of national road system.

Muddy road, not even surface=compacted is highway=primary in some region.

so it doesn't appear on OSM till you zoom right in,
is it mistagged as highway=track? Then it is a data issue, not rendering issue.
but it's also the only "main" road for 1000 k's in any direction, so you would think that it should be shown at high level zoom?
Is it correctly mapped with proper highway tag?
Same, same with the (OSM) villages / hamlets / remote dwellings that this road serves. A single building out in the middle of nowhere, in the OSM universe, is too small & insignificant to be noticed, but that pub, with attached service (gas) station, general store & camping ground, is also the major point of civilisation for that 1000 k's!, so how important is it in real life to those people who are travelling through that area? Extremely!
This is sadly a hard to resolve rendering issue. Special purpose rendering of OSM data
may be helpful for such areas.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Quality and the Openstreetmap value chain

Graeme Fitzpatrick

On Wed, 13 May 2020 at 11:13, Mateusz Konieczny via Tagging <[hidden email]> wrote:

Dirt road may be highway=trunk if it is the main road of national road system.
Muddy road, not even surface=compacted is highway=primary in some region.

is it mistagged as highway=track? Then it is a data issue, not rendering issue.

Currently tagged as highway=secondary, so I'll have a look at upping them to primary / trunk, thanks.
Same, same with the (OSM) villages / hamlets / remote dwellings that this road serves. A single building out in the middle of nowhere, in the OSM universe, is too small & insignificant to be noticed, but that pub, with attached service (gas) station, general store & camping ground, is also the major point of civilisation for that 1000 k's!, so how important is it in real life to those people who are travelling through that area? Extremely!
This is sadly a hard to resolve rendering issue. Special purpose rendering of OSM data may be helpful for such areas.

The concept of mapping "villages" as towns to make them show has been discussed several times on the Aussie list! Yes, yes, it's tagging for the renderer, but sometimes that seems to be the only way around things?

Thanks

Graeme


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Quality and the Openstreetmap value chain

Marc M.
In reply to this post by Graeme Fitzpatrick
Hello,

Le 13.05.20 à 00:18, Graeme Fitzpatrick a écrit :
> I'd really like somebody to come up with simple definitions of

let's try :)

> mappers,

someone who adds data into osm

> data consumers / customers,

someone who get data from osm

> I map, & I then also "use" OSMand for navigation purposes, so what am I?

a mappers and a user of OSMand (by using OSMAnd, you don't use the data
directly, if a tag changes, it is osmand that has to change and not you
as an osmand user).

Regards,
Marc

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Quality and the Openstreetmap value chain

Shawn K. Quinn
In reply to this post by Graeme Fitzpatrick
On 5/12/20 17:18, Graeme Fitzpatrick wrote:
> I'd really like somebody to come up with simple definitions of
>
> mappers,
>
> data consumers / customers,
>
> users?

I'd consider "user" and "data consumer" to be the same thing (but would
prefer "user" or even "data user" in light of the objection to
"consumer" used in this context at
<https://www.gnu.org/philosophy/words-to-avoid.html#Consumer>).

A "user" is someone who makes use of the data generated by the
OpenStreetMap project including its volunteers. A "mapper" (or "editor")
would be someone who creates and/or updates the data for the project.
One easily can be both at different times, in fact, I would hope most if
not all mappers "eat their own dog food" and use OSM data as much as
possible in preference to e.g. Google or Bing maps.

--
Shawn K. Quinn <[hidden email]>
http://www.rantroulette.com
http://www.skqrecordquest.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1234