Re: [Potlatch-dev] Potlatch 2.3
Hi! Small update: After moving from the test installation to the live instance, the locale does work. Though I have no idea why as nothing has changed in the embedding. Maybe some flash caching issue? Now that it basically works, I noted that the translation of the UI is still incomplete. osm.org shows the same mix of English and German. I filed a ticket on trac and I would be happy to provide the German translation once the additional injections are in place. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch-dev-Potlatch-2-3-tp6848644p7057442.html Sent from the Potlatch mailing list archive at Nabble.com. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Harmless edits (was: Change in wtfe.gryph.de Quick History Service API)
On Sat, Dec 03, 2011 at 01:13:14AM +0100, Frederik Ramm wrote: Everyone is invited to play with this script and see what happens. I plan to make this the basis of the v2 WTFE service, meaning that in the future editors will likely *not* highlight stuff that my script deems harmless. Here's the - hacky, perly - source code: http://wtfe.gryph.de/harmless.pl Please don't do mass evaluations with this web service, as it runs a history query against the API in the backend and this is quite costly. If you want to run this on a large area, download the .pl file and make yourself a full history extract with Peter Koerner's history splitter, then run the perl script on the XML. It can process anything up to the complete planet if you have the patience. Just a reminder on the side: Simon Poole provides history extracts for some countries here: http://odbl.poole.ch/extracts/ They are softcut using the polygons from Geofabrik. Might come in handy here. Sarah ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Harmless edits (was: Change in wtfe.gryph.de Quick History Service API)
Hi, On Sat, Dec 03, 2011 at 01:13:14AM +0100, Frederik Ramm wrote: I have finalized a script that can analyze an object's history and determine if certain edits are non-edits (i.e. nothing of note was changed at all), or harmess (i.e. the object was changed and might have to be rolled back if the contributor does not agree to the license change, but the rollback will likely not affect the quality much). [...] You can try out my script here, by adding a way/node/relation id to the URL like so: http://wtfe.gryph.de/harmless/way/40103577 The output is a break-down of what my script thinks has happened to the object, and which edits are zero-edits (severity: 0) or harmless (severity: 1). After the version analysis, it summarizes the user contributions - each user is afforded the highest severity of all his changes. There is a small oddity: when a non-agreeing user deleted an object then the script notes that down as a zero-edit and ignores the fact that the object is gone. Example: http://wtfe.gryph.de/harmless/node/1300187843 see history: http://www.openstreetmap.org/browse/node/1300187843/history Might happen only if there are no tags. I'm also slightly confused by the user summary. What do 'relevant change' and 'no change' mean? I would have expected 'relevant change' to be only those that are non-zero edits by non-agreers but that does not seem to be the case. Sarah ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Harmless edits
Hi, On 12/03/2011 12:01 PM, Sarah Hoffmann wrote: There is a small oddity: when a non-agreeing user deleted an object then the script notes that down as a zero-edit and ignores the fact that the object is gone. Example: Indeed. While not relevant for the kind of processing I had in mind (colouring existing objects) that should be fixed to avoid misunderstandings. I'm also slightly confused by the user summary. What do 'relevant change' and 'no change' mean? I would have expected 'relevant change' to be only those that are non-zero edits by non-agreers but that does not seem to be the case. Yes, that is maybe an unfortunate choice of wording on my part. Our *default* assumption is that any edit by a non-agreer makes an object problematic. If an agreer makes a harmless change, or if a non-agreer makes a significant change, then that doesn't change anything compared to our default assumption. If, on the other hand, a non-agreer's change is found to be harmless, then *that* is a relevant change in so far as it might actually change the colour of an object on the map (from orange to not shown or whatever). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Harmless edits
Am 03.12.2011 12:38, schrieb Frederik Ramm: Hi, On 12/03/2011 12:01 PM, Sarah Hoffmann wrote: There is a small oddity: when a non-agreeing user deleted an object then the script notes that down as a zero-edit and ignores the fact that the object is gone. Example: Indeed. While not relevant for the kind of processing I had in mind (colouring existing objects) that should be fixed to avoid misunderstandings. There are two aspects to this - is object deletion an operation that we consider trivial and not worthy of protection. Wrong mailing list for that discussion, but if the answer is no (unlikely IMHO) we would actually have to undo the deletions - we will want to keep a list (a map) of such objects for potential replacement of objects that were replaced by non-agreers (non-agreer deletes a object and creates a new object in its place) Simon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] osm2psql -r primitive xml parsing
hi, That might not be a bug since, as the option suggest, it's primitive but this parsing mode doesn't seams to support xml entities in key's values, like #39; for ' and ends inserted in the db as #39; PS: I know I'd better switch to pbf files imports to speed-up the import. -- sly (sylvain letuffe) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Harmless edits
Am 03.12.2011 19:36, schrieb Frederik Ramm: Hi, On 12/03/2011 01:07 PM, Simon Poole wrote: - is object deletion an operation that we consider trivial and not worthy of protection. Wrong mailing list for that discussion, but if the answer is no (unlikely IMHO) we would actually have to undo the deletions And when a denier creates an object and another denier deletes it we vanish in a puff of logic ;) Perhaps I'm stupid or so, but I don't see where the paradox is supposed to be. If we consider what we are doing as rolling back in time edits done by decliners everything would seem to be completly consistent. In any case what is this discussion doing on dev? - we will want to keep a list (a map) of such objects for potential replacement of objects that were replaced by non-agreers (non-agreer deletes a object and creates a new object in its place) I thought about this but I guess it's not worth the effort since you'd be resurrecting stuff that has been collecting dust in hiding for, potentially, years and therefore might be quite inaccurate. Deleted objects may still contain useful information, obviously resurrection should be done thoughtfully. Simon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] support for Openstreetview in JOSM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey Jo Am 28.11.2011 21:43, schrieb Jo: Wishlist: - Ability to upload these geotagged pictures directly to the FTP server of Openstreetview The first time a username/password should be asked for and it needs to be stored in JOSM's settings - Ability to download all available photos for a given area (maybe as an extra tick in the download window? Just like for GPX tracks of other contributors) I digged up this Perl snippet: http://linux.voyager.hr/osm/openstreetview_dl.txt I can't claim I understand it, but I believe it could give a clue on how to achieve such a download. Should I ask for this functionality as a trac ticket? Is it one request, or two separate ones? ... Yes, Trac is the place for enhancements and wishes. I think one ticket is enough. This sounds more like a new plugin or maybe some extra functions of 'EXIF photo geotagging'. Cheers colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk7aGSEACgkQalWTFLzqsCtNxwCg2rbrL9cLwdVhDIuiaOCM0q4Y qLcAoLXQli0pFdz9AC5kw9AW6Im5chS/ =ZbZx -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Trac: OperationalError: database is locked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey guys. Just want to make sure you notice (hope you are working on it) I get OperationalError: database is locked on the ticket system for new tickets and requesting filtered ticket list. Opening tickets directly works. Ciao colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk7aHIoACgkQalWTFLzqsCuwEgCgoOfwEgD4i4oNZhDgM43WdUAC PQ4AoNsVah1Y+V+smJwHuMRIwgr+LukU =pQRt -END PGP SIGNATURE- ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Trac: OperationalError: database is locked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 03.12.2011 13:56, schrieb colliar:
Hey guys.
Just want to make sure you notice (hope you are working on it)
I get OperationalError: database is locked on the ticket system for new
tickets
and requesting filtered ticket list. Opening tickets directly works.
Ciao
colliar
Sorry forgot:
Zum Reproduzieren
Während der Ausführung von GET auf `/report/6` hat Trac einen internen Fehler
gemeldet.
''(Bitte geben Sie hier weitere Details an)''
Anfrageparameter:
{{{
{'id': u'6'}
}}}
User agent: `#USER_AGENT#`
Systeminformationen
''Systeminformation nicht verfügbar''
Aktive Plugins
''Plugininformation nicht verfügbar''
Python-Zurückverfolgungsinformationen
{{{
Traceback (most recent call last):
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/web/main.py,
line 511, in _dispatch_request
dispatcher.dispatch(req)
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/web/main.py,
line 260, in dispatch
req.session.save()
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/web/session.py,
line 105, in save
@self.env.with_transaction()
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/db/api.py,
line 77, in transaction_wrapper
fn(ldb)
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/web/session.py,
line 140, in save_session
, (self.sid, authenticated))
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/db/util.py,
line 65, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/db/sqlite_backend.py,
line 78, in execute
result = PyFormatCursor.execute(self, *args)
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/db/sqlite_backend.py,
line 56, in execute
args or [])
File
/usr/local/lib/python2.6/dist-packages/Trac-0.12.2-py2.6.egg/trac/db/sqlite_backend.py,
line 48, in _rollback_on_error
return function(self, *args, **kwargs)
OperationalError: database is locked
}}}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEAREIAAYFAk7aHY4ACgkQalWTFLzqsCt9qwCfdN1nmbNnF+jQaD5vioyQ8Vwa
x50AnicdINmzdYSHgPsI2IS+OT46aUA/
=iewp
-END PGP SIGNATURE-
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Trac: OperationalError: database is locked
On Sat, 3 Dec 2011, colliar wrote: Just want to make sure you notice (hope you are working on it) I get OperationalError: database is locked on the ticket system for new tickets and requesting filtered ticket list. Opening tickets directly works. This is basically an issue caused by too much load on the machine. And this again seems to be caused by hanging Apache requests. I'm investigating this for some time now, but did not really find the cause. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
