>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
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 :
> >There's one more face to iD and mistakes users make: translations.
> >Bad translations cause bad tagging.
> > Example: "track" w
>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 info
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 al
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 mak
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 wrote:
> Thank you for dismissing all our arguments in one fell swoop. The
> difference with reported
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 br
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 interes
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 abou
On Wed, Feb 11, 2015 at 4:41 PM, Andrew Wiseman 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
talk@openstreetmap.org
http
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
Y
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 everyth
On Wed, Feb 11, 2015 at 1:08 PM, 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.
>
This goal does not appear to have been carried out.
The iD project comes off as tone dea
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 wrote:
> We have been saying
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 something
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 tha
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 wrote:
> On Wed, Feb 11, 2015 at 9:59 AM, Tom MacWr
On Wed, Feb 11, 2015 at 9:59 AM, Tom MacWright 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
> give that perso
On Wed, Feb 11, 2015 at 8:47 AM, Tom MacWright 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 requests "tightly h
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% of
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 opposi
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 arou
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 l
On Wed, Feb 11, 2015 at 11:39 AM, Bryce Nesbitt
wrote:
> On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright 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
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
wrote:
On Wed, Feb 11, 2015 at 8:25 AM, Tom MacWright 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.
>
>
Productive fe
>
> 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
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
> 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
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
d
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 ? S
32 matches
Mail list logo