https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=1373627312
has only 35 rows.
2015-02-13 8:22 GMT+01:00 Imre Samu pella.s...@gmail.com:
There's one more face to iD and mistakes users make: translations.
Bad translations cause bad tagging.
has only 35 rows.
17 word pair + 1 header record
There are other worksheets , you can switch/change at the bottom of the
page:
Direct links:
*meta_pl : meta data ...*
https://docs.google.com/spreadsheets/d/1CLt3l_ZQhKFRH5YmfGzo3VJNLQHtHiZSBva3ldU_jJs/edit?pli=1#gid=2147407685
Since two years ago, iD has an range of validations it runs on every
potential changeset, as well as an interface to review correct potential
errors before saving them.
https://github.com/openstreetmap/iD/blob/master/js/id/validate.js#L1
We welcome contributions to expand these, and have a few
I was wondering, what do you think (interpret this only as a question)
about introducing validation in iD in the future?
Using MAGIC integrated circuit design tool, that does DRC (Design Rule
Check) in real time and highlights errors inspired me that OSM editors
could also incorporate this. It
Whoops. Good to know. Though it's still rudimentary ;) Not long ago I
tried to do intentionally do stupid things in iD demo in order to see
if it would stop me - it didn't.
There's one more face to iD and mistakes users make: translations. Bad
translations cause bad tagging. English terms don't
There's one more face to iD and mistakes users make: translations.
Bad translations cause bad tagging.
Example: track was translated to Polish .
Good translation is very important for the beginners.
and _now_ not so easy to check the quality of the iD translations.
I would like to inform
On Wed, 11 Feb 2015 16:08:37 -0500,
Tom MacWright wrote:
Ever since 2012, in the second commit ever, Not breaking other
people's data has been one of the three clearly stated public design
goals of iD.
Regarding this statement it is interesting that iD went live with no
graphic hints about
Thank you for dismissing all our arguments in one fell swoop. The
difference with reported bugs, is that said bugs did get addressed. If we
are anti-anything it's
anti-having-to-cleanup-with-no-possibility-to-shut-close-the-source-of-the-cause-of-precious-time-wasters.
If people were consciously
Am 12.02.2015 um 14:27 schrieb malenki:
On Wed, 11 Feb 2015 16:08:37 -0500, Tom MacWright wrote:
Ever since 2012, in the second commit ever, Not breaking other
people's data has been one of the three clearly stated public design
goals of iD.
Regarding this statement it is interesting that
ICYMI, Richard Fairhurst contributed a patch to fix this problem that we're
currently reviewing for inclusion:
https://github.com/openstreetmap/iD/pull/2526
On Thu, Feb 12, 2015 at 10:01 AM, Jo winfi...@gmail.com wrote:
Thank you for dismissing all our arguments in one fell swoop. The
How is an open source project that was open source on day one, was publicly
communicated from day one, heavily explained in time-consuming technical
blog posts, has 77 contributors, and has accepted hundreds of pull requests
tightly held.
On Wed, Feb 11, 2015 at 11:39 AM, Bryce Nesbitt
On Wed, Feb 11, 2015 at 11:39 AM, Bryce Nesbitt bry...@obviously.com
wrote:
On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright t...@macwright.org wrote:
Unfortunately, experience suggests that there's relatively little that a
discussion on on the talk mailing list is going to be able to do here.
Unfortunately, experience suggests that there's relatively little that a
discussion on on the talk mailing list is going to be able to do here.
This. Help with development or give productive feedback on the issue
tracker. FUD around editors has been discussed to death and it's clear that
On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright t...@macwright.org wrote:
Unfortunately, experience suggests that there's relatively little that a
discussion on on the talk mailing list is going to be able to do here. Help
with development or give productive feedback on the issue tracker.
I agree 100% that iD is making editing mistakes easier, out of proportion
to the degree to which it makes editing by new users easier.
The delete user interface is particularly fragile, encouraging the most
pernicious form of damage: silent deletes.
That goes for both the main map, and associated
Jo Walsh wrote:
On the one hand I'm sorry to hear that communicating and fixing is a
distraction from mapping for you,
I understand how he feels:
When I happen to correct a lot of stupid errors sometimes I feel like
there are a lot of stupid mappers. :)
on the other you're starting to sound
Folks,
This post doesn't represent the DWG in any way, but as someone who
does DWG work, and closely monitors his local area, I think I have a
bit of expertise in this area.
In my experience, iD users do not make any more mistakes than any
other editor in relative terms. In other words- if 80%
Hi,
Am 2015-02-11 um 17:25 schrieb Tom MacWright:
Unfortunately, experience suggests that there's relatively little that a
discussion on on the talk mailing list is going to be able to do here.
This. Help with development or give productive feedback on the issue
tracker. FUD around
That ticket doesn't have a difference of opinion: it has a core developer
of iD offering to buy a cake for whoever contributes a fix. Nobody has
contributed a fix: one would be accepted if it was contributed. Plus, we'd
give that person a cake.
That isn't a difference of opinion: there's no
We have been saying this from the very beginning, so it should have been
taken into account right from the very start of development of iD.
Don't break other contributor's data should have been among the initial
design goals. Don't bother the user with dialogs when they're about to
break
On 2/11/2015 2:49 PM, Bryce Nesbitt wrote:
Read through the issue tracker: It's clear that issues reported are
pushed back on by the core iD developers. It's very tightly held.
I disagree (not a developer here). The interesting thing that came
out of this discussion is the realization that
On Wed, Feb 11, 2015 at 8:47 AM, Tom MacWright t...@macwright.org wrote:
How is an open source project that was open source on day one, was
publicly communicated from day one, heavily explained in time-consuming
technical blog posts, has 77 contributors, and has accepted hundreds of
pull
On Wed, Feb 11, 2015 at 9:59 AM, Tom MacWright t...@macwright.org wrote:
That ticket doesn't have a difference of opinion: it has a core developer
of iD offering to buy a cake for whoever contributes a fix. Nobody has
contributed a fix: one would be accepted if it was contributed. Plus, we'd
There's no magic to working on iD: 77 people of varying skill levels have
done it. It takes time. If this is important to you, I'd suggest you invest
that time rather than ordering other people to.
On Wed, Feb 11, 2015 at 2:53 PM, Bryce Nesbitt bry...@obviously.com wrote:
On Wed, Feb 11, 2015
Ever since 2012, in the second commit ever, Not breaking other people's
data has been one of the three clearly stated public design goals of iD.
https://github.com/openstreetmap/iD/commit/22fab3eb1d259fe73d3e1498df1ca0e07c613f87
On Wed, Feb 11, 2015 at 4:00 PM, Jo winfi...@gmail.com wrote:
We
We also aimed to have no bugs and like every software project before us,
have failed to achieve that goal.
The uproar about iD is the same as the uproar about the map style, website,
user groups, code of conduct, Steve Coast, the board, imports, license
change, attribution, and practically
On Wed, Feb 11, 2015 at 1:08 PM, Tom MacWright t...@macwright.org wrote:
Ever since 2012, in the second commit ever, Not breaking other people's
data has been one of the three clearly stated public design goals of iD.
This goal does not appear to have been carried out.
The iD project comes
Maybe this is an obvious one, but why not just write the user who made the
error a nice note? One of my first edits was an error, and somebody (Jaakko
Helleranta from HOT, it turns out) wrote me a nice note, something like
hey, thanks for editing, I notice you did X but probably should have done
On Wed, Feb 11, 2015 at 4:41 PM, Andrew Wiseman awise...@gmail.com wrote:
People who want to edit a map are generally nice people.
+1
--
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
On 10/02/2015 23:38, colliar wrote:
... I am fed up with ...
... at this point it's probably worth mentioning that we've been here
before:
https://lists.openstreetmap.org/pipermail/talk/2013-August/thread.html#67854
Unfortunately, experience suggests that there's relatively little that a
What might help here is to get details from the new mapper concerned of
how they felt that they needed to merge nodes or ways.
I use changeset discussions a fair bit, partly because they end up right
in the new mapper's inbox, and that provides a link to an outside view
of the new mapper's
Hey
Maybe, it is me only to slow in reverting and solving these mistakes or
even the bugs I incounter in JOSM while working but I am definitely feed
up with talking about the same things over and over again and I am
probably not even polite enough to do the job of communicating.
So what to do ?
32 matches
Mail list logo
