in a 12-hour editing session, a very simple analysis would suggest
about a 0.5% chance of conflicts. this isn't very much, imho
cheers,
matt
it's running only for a week and I have already the first conflict.
and it's max 2h edit. session
latest JOSM resolved all conflicts so no big
On Sat, 08 Aug 2009 06:03:37 +0300, Eugene Alvin Villar sea...@gmail.com
wrote:
On Wed, Jul 22, 2009 at 6:44 PM, John Smith delta_foxt...@yahoo.com
wrote:
However it'd be nice for editors to strip it out automatically.
-1
I don't favor editors stripping out created_by=* tags
On Sat, Aug 8, 2009 at 11:32 AM, Teemu Koskinen teemu.koski...@mbnet.fiwrote:
On Sat, 08 Aug 2009 06:03:37 +0300, Eugene Alvin Villar sea...@gmail.com
wrote:
On Wed, Jul 22, 2009 at 6:44 PM, John Smith delta_foxt...@yahoo.com
wrote:
However it'd be nice for editors to strip it out
--- On Fri, 31/7/09, Andy Allan gravityst...@gmail.com wrote:
Each diff upload would take about 100 seconds, each
changeset would take
about 40 minutes, we'd be doing about 30-35 changesets
per day and finish
the thing after about 100 days (some time in November
if we start soon).
wait a second,
this will create a lot of editing conflicts when editing in Josm. Not
sure how Potlatch does it in save mode.
Josm still has some bugs in the conflict resolution. Can we delay
until Josm is 100% master of conflict resolution.
one bug was fixed today, filed a new ticket today
Matt Amos wrote:
in a 12-hour editing session, a very simple analysis would suggest
about a 0.5% chance of conflicts. this isn't very much, imho
And then only if you're editing the USA data.
--
Lennard
___
dev mailing list
Hi Frederik,
when a way is deleted in JOSM the nodes with tags remain in the db.
this causes tons of orphans.
is it possible to delete these nodes in the same cleanup.
after deleting the tiger tags it's difficult to identify these useless
nodes without a full history lookup.
check should be
Hi,
Apollinaris Schoell wrote:
when a way is deleted in JOSM the nodes with tags remain in the db.
this causes tons of orphans.
is it possible to delete these nodes in the same cleanup.
It would certainly be preferable, *if* these nodes are really useless,
to remove them instead of burdening
--- On Wed, 22/7/09, Marc Schütz schue...@gmx.net wrote:
Should the editors be changed to automatically remove
created_by? Or maybe just well-known values like /JOSM.*/,
/Potlatch.*/?
Right, wrong or indiff I've been removing them on things I edit as I see them
as a waste, since it only
On Wed, Jul 22, 2009 at 10:46 AM, John Smith delta_foxt...@yahoo.comwrote:
--- On Wed, 22/7/09, Marc Schütz schue...@gmx.net wrote:
Should the editors be changed to automatically remove
created_by? Or maybe just well-known values like /JOSM.*/,
/Potlatch.*/?
Right, wrong or indiff
On 22 Jul 2009, at 10:39, Marc Schütz wrote:
what about created tags? they are pretty much useless too.
2G difference on the uncompressed planet file.
Now that the editors are ignoring the created_by tag when creating
and
changing objects, the tag will slowly decrease over time. There is
Russ Nelson wrote:
Where the TIGER data is in good shape, they do line up exactly. I can
point you to some examples. Can you point me to some examples where
they don't line up?
I think practically along every county border I have followed in
northern California. I have connected/joined
This is all redundant information. Be bold, delete it.
80n
On Fri, Jun 26, 2009 at 5:59 PM, Andy Allan gravityst...@gmail.com wrote:
Hello Devs,
source = tiger_import_dch_v0.6_20070813
tiger:county = St. Louis, MO
tiger:tlid = 100111260:100111261:10055:10059
tiger:upload_uuid =
2009/6/27 Minh Nguyen m...@zoomtown.com:
Ngày 6/26/09 12:59 PM, Andy Allan viết:
Hello Devs,
source = tiger_import_dch_v0.6_20070813
tiger:county = St. Louis, MO
tiger:tlid = 100111260:100111261:10055:10059
tiger:upload_uuid = bulk_upload.pl-6143e1a9-589d-43a0-9248-e95658773ef4
On Sat, 2009-06-27 at 09:26 +0100, 80n wrote:
This is all redundant information. Be bold, delete it.
Indeed. Leave it in the ways, remove it from the nodes.
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Indeed. Leave it in the ways, remove it from the nodes.
Is this a low (database) level delete? Or will we gain a new history
entry for every node showing the node as it was before the delete
and as it was after? If the latter then won't the database end up
bigger rather than smaller?
Ed
2009/6/27 Ed Loach e...@loach.me.uk:
Indeed. Leave it in the ways, remove it from the nodes.
Is this a low (database) level delete? Or will we gain a new history
entry for every node showing the node as it was before the delete
and as it was after? If the latter then won't the database end
Greg Stark wrote:
Also, are ways actually entirely in one county or another? It seems to
me they would often span borders.
That is how they are reported to the census bureau. Every county reports
on the parts of roads that lie within its borders.
They rarely match up exactly enough at the
On Jun 27, 2009, at 10:16 AM, Stellan Lagerstrom wrote:
Greg Stark wrote:
Also, are ways actually entirely in one county or another? It seems
to
me they would often span borders.
That is how they are reported to the census bureau. Every county
reports
on the parts of roads that lie
Hello Devs,
source = tiger_import_dch_v0.6_20070813
tiger:county = St. Louis, MO
tiger:tlid = 100111260:100111261:10055:10059
tiger:upload_uuid = bulk_upload.pl-6143e1a9-589d-43a0-9248-e95658773ef4
Stuff like this appears on every node in the US, which is a pain. I
reckon it's all
20 matches
Mail list logo
