Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
Stephan Knauss wrote: Das ist egal. Die Bilder sind sauber. Potlach hat aus irgendwelchen Gründen beschlossen diese Bereiche zu verschleiern. You are certifiably insane. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Potlach-2-kein-bing-Hintergrund-Bild-mehr-bei-Militaerflaechen-tp5437617p5437881.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Potlatch and relation handling
(Sorry, tried to send this yesterday but my subscription to talk-de appeared to have died! Apologies in advance for posting in English.) Tirkon's claim about Potlatch and relation handling is complete nonsense. To edit a relation in Potlatch 2: * select a node or way which is a member of that relation * select 'Advanced' on the left to see the relation list * double-click the relation Then, click 'Members' to see the members in order. You can change the order by dragging the list entries. To add this relation to another, 'parent' relation, click 'Advanced' and then 'Add to'. So there you go, full support for nested and ordered relations. Tirkon, I would be grateful if you would stop repeating the claim that there is no support. Martin, I've long since stopped expecting anything you say to be founded in any form of reality. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
Martin Koppenhoefer wrote: So in the end I am happy that someone recently coded the missing relation support for Potlatch2, but given your statements from previous discussions (as well as you closing relative tickets with won't fix) wasn't really encouraging to think that this has been done in the past few weeks. What on earth are you on about? Potlatch 2 has full support for nested and ordered relations. Potlatch 2 has _always_ had full support for nested and ordered relations. That is what Tirkon was disputing in his wiki posting to which http://lists.openstreetmap.org/pipermail/talk-de/2011-December/090998.html referred; that is what you supported in the follow-up message, http://lists.openstreetmap.org/pipermail/talk-de/2011-December/091009.html; and that is what I was correcting. This has absolutely nothing to do with whether Potlatch 2 has an abstraction model for one particular (broken) tagging paradigm, by which tags created in simple mode are applied to a 'containing' multipolygon relation rather than the way itself. That is the subject of your trac tickets. I have already explained why, given the likelihood of a proper area datatype to replace this nasty hack, I will not spend my own time coding that; but suggested: If you want it to be changed to additionally support tagging the relation, submit a good patch. I will be happy to help with the coding and UI issues for this patch. and again: if someone else who does come from a land where people use bonkers complicated multipolygons came up with a decent patch, I imagine we'd be very happy to accept it. But I realise that would require you to actually do some work rather than just endlessly, parasitically criticising others' work on the mailing lists. Richard -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch-and-relation-handling-tp7089701p7089929.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
Martin Koppenhoefer wrote: Btw: I am not aware of the concept of parasitical criticism, what do you intent? - reply offlist preferred to keep the noise low Replied offlist. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch, die Siebenundzwölfigste
Ralf Otmanns wrote: Potlatch mag sein ein tolles Tool sein, ein gut gemeintes Tool ... leider wissen vielleicht 2 % der Leute, die es verwenden, was sie da tun. Ihr wisst ja, dass gut gemeint das Gegentum zu gut ist. Der Rest sind wie 4jährige, denen Du Malstifte gibst und sie dann in ein frisch tapeziertes Zimmer sperrst. I get intensely frustrated when people complain about aspects of an open source project like OSM, but don't actually _do_ anything about it. All the code for Potlatch is public domain, freely available, in the main OSM repository, and in a well-known and well-documented language, with a free compiler. http://trac.openstreetmap.org/browser/applications/editors/potlatch/ Patches are welcome. If you submit patches to bugs you've noticed, that's great. If you submit patches to any of the outstanding trac tickets, that's _really_ great, because it means I can spend less time on these and more time improving usability - such as the online help feature planned for Potlatch 1.0. For example, you could fix http://trac.openstreetmap.org/ticket/954, which is really difficult for me to do because I don't actually have a German keyboard. If someone else saves me an afternoon hacking on that, the online help gets one afternoon nearer. Maybe you can't program. That's fine. There are still a lot of ways in which you can help. Several people on this list have put a lot of time into localising Potlatch and improving the German-language docs on the wiki, and I'm enormously grateful to them. Why not create a video screencast in your native language, showing newbies how to use Potlatch? If you were to upload it to YouTube I could perhaps even use their API to integrate it into Potlatch, so that new users could click to see the tutorial before they start. If you feel there are things about Potlatch that need improving, then come and help. There are only 24 hours in the day, I can't do it all myself. Don't just sit here and whinge. Particularly, at least have the common courtesy to cc: your complaints to the developer, rather than bitching off behind his back in a language which he doesn't understand (except via Google Translate ;) ) and on a list which he very rarely reads. Oh, and 2%? Come on, you only weaken your case with such utterly absurd exaggerations. As a _mapper_ I'm offended by your suggestion that I'm 98% likely not to know what I'm doing, simply because of my choice of editor. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Potlatch (Re: Multi-User randale ( s?dlich Reutlingen/T?bingen ))
Apologies, as a non-German speaker I can only half-follow this discussion through Google Translate, and I realise it's very rude to post in English on a German-speaking list. I thought it would nonetheless be valuable to follow up two points in particular, hope you don't mind. Andre Rechelt wrote: Ich frage mich ganz einfach, was sich die Entwickler von Potlach heraus nehmen, um im Gegensatz zu ALLEN ANDEREN direkt in der Datenbank herumzupfuschen und nicht den Weg ?ber die API gehen. Potlatch does not have, as you have put it elsewhere, a direct tunnel to the data. This just isn't true. Potlatch (the application) uses an API, just as JOSM does, which sanitises requests, requires authentication, etc. There are three significant differences between that part of the API used by Potlatch, and that part of the API used by JOSM etc. - Potlatch uses a different encoding (AMF rather than XML). This is simply for the sake of efficiency: older (Actionscript 1)/free (Gnash) Flash players work much better with AMF than with XML. Encoding, of course, makes no difference to the data. - Some of Potlatch's calls are constructed differently. Some of this is for historical reasons - you might be too new to realise this, but in earlier versions of the API, we had three object types: ways (comprising a chain of segments), segments (connecting two nodes), and nodes. Potlatch (which has always had broadly the same UI) abstracted segments away from the user. Therefore the API functions provided _at_the_time_ were not particularly suitable. Since then, the rest of the API has in fact moved closer to Potlatch through the abolition of segments (Frederik and Gabriel's work, thanks :) ). I believe that there is some will to provide the rest of the API with the remaining Potlatch-only functionality (in particular, a PUT /way/id/full method). Bear in mind too that, at present, the design of the main API calls are better suited to an offline editor (like JOSM) than an online one (like Potlatch). In particular, the /map call pulls down the entire contents of the bounding box every single time. This would mean that, every time the user panned the map in Potlatch, all the ways and nodes would be sent again - even if the user had only panned left by 10% of the screen area. Instead, Potlatch takes an approach which does not require already-loaded ways to be resent, with significant benefits for bandwidth and server load. - A significant proportion of the code in amf_controller.rb uses SQL rather than Rails objects. Except in some cases where SQL provides a significant speed advantage, this is generally accepted as a defect. It's only the case because I don't speak Rails. If you want to do something constructive, fixing this would be the single best place to start, and would be enormously welcomed by many people including myself. Please take it forward to the dev list if so - you'll find lots of people willing to help you! While I'm here I might as well say something about the lack of a Save button. I'm not violently against the concept: I think unconvinced is perhaps the best way to describe my opinion. There are two big issues with it. One is that for edit sessions lasting more than a couple of seconds, there has to be conflict management. If you're a JOSM user, then you are de facto a clued-up, computer-savvy type, so conflict management doesn't worry you. But if you are a newbie - maybe even a schoolkid - trying just to edit your local area, then being presented with The following conflicts were detected. Accept/Resolve/Revert? will just utterly confuse you, and you'll click the wrong thing and cause more errors. Or maybe just close Potlatch and never return to OSM. The second is that, in JOSM, your canvas is usually quite small - i.e. you have downloaded a particular area and are working on that exclusively. In Potlatch, because you can pan around an infinite map, your canvas may be much bigger. You may have traced a 600km cycle route (I know, I've done that! :) ) in one session. Yet you can't zoom out to see the whole thing, because requesting a 600km bounding box would break both the server and the browser. So you would be clicking Save to upload changes that you can't actually see or review, and that - in my opinion - defeats the point of it. But actually they're not my biggest problem with the idea. What worries me most, because I've seen it before, is that people are seizing on the first thing they don't like, and thinking that's the reason why there are bad edits. People used to criticise Potlatch for causing bad edits because there was no 'revert' feature, so I added a revert feature (the H key). Then they criticised Potlatch for causing bad edits because there was no 'test' mode, so I added a test mode. Then they criticised Potlatch because there was no 'splash screen'
