hi,
the last weeks have been quite horrible here, but at least I managed
to write some kind of framework for the MEP:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Pipeliner
as if there isn't enough on my shoulders right now, I've been called
away on short notice for the next 6 weeks; I
On 09/01/15 13:12, Frederik Ramm wrote:
Just to be clear, the core of my idea was some kind of subscription
mechanism where you, as a data user, could say: I am processing these
tags in my application and I wish to be notified of important changes.
I wasn't even thinking about the input side
Hi,
(full-quoting as an exception here)
Just to be clear, the core of my idea was some kind of subscription
mechanism where you, as a data user, could say: I am processing these
tags in my application and I wish to be notified of important changes.
I wasn't even thinking about the input side
I think there is a big difference between getting information from
templates (very guided and structured) and completely understand the whole
wiki.
Such software supplying information about tags would be to get them from
the ValueDescription template and give a link to the wiki page if human
want
2015-01-06 13:34 GMT+01:00 François Lacombe fl.infosrese...@gmail.com:
As Frederik suggested, I'm strongly in favor of software supplying
information about tags.
The wiki can be understood by humans but not so readable by machines.
I am not against software supplying information about tags,
Dana 7. 1. 2015. 03:53 osoba Bryce Nesbitt bry...@obviously.com
napisala je:
While we're at it, it would be nice to have a database that allows going
from the tagged item (e.g., fitness centre) to recommended tag.
The iD editor has a nice internal feature called aliases, so a person
looking
Maybe derailling and off-topic but anyway I do agree...
To be discussed on tagging, dev, ...?
While we're at it, it would be nice to have a database that allows going
from the tagged item (e.g., fitness centre) to recommended tag.
The iD editor has a nice internal feature called aliases, so a
On 07/01/2015 5:37 AM, althio althio wrote:
Maybe derailling and off-topic but anyway I do agree...
To be discussed on tagging, dev, ...?
While we're at it, it would be nice to have a database that allows going
from the tagged item (e.g., fitness centre) to recommended tag.
The iD editor has
Hi,
On 01/03/2015 06:22 PM, Chris Hill wrote:
What about the maps I produce for my client? You're not likely to know
about it as it is a private project. If you make a mechanical edit that
breaks my render, should I send the bill for the changes to you rather
than ask my client to pay?
That
On 1/6/2015 6:47 AM, Chris Hill wrote:
If the new scheme is adopted in staged way that would be better than a
single mass edit, though it can still break data use for people who
don't follow OSM's mailing lists.
I don't blame the proposer of the scheme; he's just following the daft
guidelines
+1 with Mike, there is nothing wrong with voting.
As Frederik suggested, I'm strongly in favor of software supplying
information about tags.
The wiki can be understood by humans but not so readable by machines.
We can imagine that draft of presets or renders can be dynamically
generated by
A tagging scheme, that was already in use, was being changed by a proposal,
supported by a small number of votes. Because of these votes the proposer
decided that his tagging scheme should be adopted by a mass edit. That mass
edit would have broken any use of the tagging scheme by data
On 03/01/15 22:05, François Lacombe wrote:
I include some mechanical edits as vandalism, other than that,
vandalism has not caused me any problems at all.
I was too.
And I don't understand why a static snapshot can't help you regarding
changes that don't suit your needs.
Think
I'm a data consumer also.
And I've faced tagging proposals that would break my imports also.
In general while I think the tagging / wiki voting system is pretty broken,
I also believe in mass re-tagging to make data more regular.
While there's a one time disruption due to re-tagging, the promise
On 06/01/2015 8:16 AM, Lester Caine wrote:
On 03/01/15 22:05, François Lacombe wrote:
...
This is possibly a case for a separate API for the management of tag
metadata? Nothing stopping private tagging, but controlling better the
core tagging infrastructure and allowing MANAGEMENT of the
While we're at it, it would be nice to have a database that allows going
from the tagged item (e.g., fitness centre) to recommended tag.
The iD editor has a nice internal feature called aliases, so a person
looking to add a restroom will find the toilet preset.
Data won't slip away because it is not tagged; it will slip away because
it is not linked.
The linking process benefits from having less coordination.
On Tue, Jan 6, 2015, at 06:06 AM, Bryce Nesbitt wrote:
You'd rather face a tag fragmentation, and slowly see your data slip
away?
It seems in
Am 05.01.2015 um 00:17 schrieb Lists:
On Jan 4, 2015, at 21:11, Richard Z. ricoz@gmail.com wrote:
On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote:
May I suggest the following work flow:
1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart
2) First date, add the new tag,
What about the maps I produce for my client? You're not likely to know about
it as it is a private project. If you make a mechanical edit that breaks my
render, should I send the bill for the changes to you rather than ask my
client to pay? (This is not hypothetical I really do have a render
May I suggest the following work flow:
1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart
2) First date, add the new tag, leave the old tag in the system. This will not
break anything, and from that date data consumers know they can start migrating
their renderers, harvesters, or
On Sat, Jan 03, 2015 at 05:22:17PM +, Chris Hill wrote:
On 03/01/15 16:50, Rainer Fügenstein wrote:
in accordance to the mechanical edit policy, I'd like to open the
discussion on this list:
a recently approved proposal introduced new tags for pipelines and
marker [1] and changed an
Lists lists at gimnechiske.org writes:
This should be the general rule for mechanical edits when migrating
tagging schemes.
Fair enough when there is a clear use that this fosters but it is unclear
whether that is true here. As a community we have to make sure that trolls
and others without our
AH Fair enough when there is a clear use that this fosters but it is unclear
AH whether that is true here. As a community we have to make sure that trolls
AH and others without our best interests at heart do not abuse our norms for
AH there own ends.
are you referring to me and the pipeline
Rainer Fügenstein rfu at oudeis.org writes:
are you referring to me and the pipeline proposal? if yes, I'll
withdraw the MEP proposal, since I don't want to be a troll.
Sorry not to make myself clear. The comment was not aimed at you and I would
like to make clear that I support the mass edit
On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote:
May I suggest the following work flow:
1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart
2) First date, add the new tag, leave the old tag in the system. This will
not break anything, and from that date data consumers know
On Jan 4, 2015, at 21:11, Richard Z. ricoz@gmail.com wrote:
On Sun, Jan 04, 2015 at 09:18:57AM -0200, Lists wrote:
May I suggest the following work flow:
1) Agree upon 2 dates sufficiently spaced i.e. 2 weeks apart
2) First date, add the new tag, leave the old tag in the system. This
in accordance to the mechanical edit policy, I'd like to open the
discussion on this list:
a recently approved proposal introduced new tags for pipelines and
marker [1] and changed an established tag:
type=* was changed to substance=*
the main reason for this change was a (possible) conflict
Hi,
Am Samstag, den 03.01.2015, 17:50 +0100 schrieb Rainer Fügenstein:
in accordance to the mechanical edit policy, I'd like to open the
discussion on this list:
a recently approved proposal introduced new tags for pipelines and
marker [1] and changed an established tag:
type=* was
CH No, just because a handful of wiki 'votes' does not mandate a mechanical
CH edit.
OK, then we'll have split data.
CH What about the maps I produce for my client? You're not likely to know
what about changing the rendering rules after the mechanical edit?
the purpose of this discussion is
I don't see any objection to do as Rainer suggested.
Maybe someone can give us examples of conflict with any other data ?
All the best
*François Lacombe*
fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux
2015-01-03 17:50 GMT+01:00
On 03/01/15 16:50, Rainer Fügenstein wrote:
in accordance to the mechanical edit policy, I'd like to open the
discussion on this list:
a recently approved proposal introduced new tags for pipelines and
marker [1] and changed an established tag:
type=* was changed to substance=*
The values
2015-01-03 18:22 GMT+01:00 Chris Hill o...@raggedred.net:
The values may need changing, e.g. type=sewer become substance=sewage
+1 indeed
What about the maps I produce for my client? You're not likely to know
about it as it is a private project. If you make a mechanical edit that
On 03/01/15 17:46, François Lacombe wrote:
2015-01-03 18:22 GMT+01:00 Chris Hill o...@raggedred.net
mailto:o...@raggedred.net:
What about the maps I produce for my client? You're not likely to
know about it as it is a private project. If you make a mechanical
edit that breaks my
2015-01-03 21:18 GMT+01:00 Chris Hill o...@raggedred.net:
I include some mechanical edits as vandalism, other than that, vandalism
has not caused me any problems at all.
I was too.
And I don't understand why a static snapshot can't help you regarding
changes that don't suit your needs.
34 matches
Mail list logo
