Re: [josm-dev] Fwd: Filter Google from Imagery?
On Fri, Jan 28, 2011 at 1:23 PM, Richard Welty rwe...@averillpark.net wrote:
On 1/28/11 12:03 PM, Anthony wrote:
Although, frankly, I've always thought the OSMF ban was more of a
don't-ask-don't-tell one. And I guess now that my contributions are
going to be deleted anyway I can come clean. I've been tracing from
Google maps for pretty much the entire time I've been contributing,
and it hasn't hurt anyone.
consider this scenario:
Google decides that open mapquest based on osm contributors
tracing from Google imagery is an issue.
they decided to sue in the US, and name the OSMF US organization
(of which i am a board member) as a party to the suit (it's normal
practice to name lots of people/organizations to such suits.
OSMF US hasn't purchased insurance to cover directors (maybe we
should, i'm going to get it on the agenda for the next board meeting).
as a result of the suit, as a director of a named party, i lose my house.
now has that hurt anyone?
something to think about.
Something for *you* to think about maybe, if you think it's something
possible. Personally I think it's absurd.
I said it hasn't hurt anyone. I never said there isn't an impossible
scenario that anyone can imagine where someone might get hurt. If we
want to invent imaginary scenarios, I'm sure I can invent one where my
*not* using Google imagery leads to someone getting hurt or dying.
On Fri, Jan 28, 2011 at 1:26 PM, Frederik Ramm frede...@remote.org wrote:
Then let's set up a second build process, somewhere outside of
openstreetmap.{de|org}, where someone who is interested in a non-OSM version
of JOSM can build releases to his heart's content and distribute them.
Releases that do not talk to the OSM server preferably, and releases that
*if* they talk to the OSM server, clearly identify themselves. OSMF could
then decide to block those releases from accessing the API at any time if
they so desire.
It sounds to me like Dirk has said he wants JOSM to be a tool which
works with any server that speaks the API, not just openstreetmap.org.
This makes sense, since the software allows people to change the API.
So, I'd say that any software specific to openstreetmap.org should be
the special build. If you want to make a compile-time option speak
only to openstreetmap.org, that sounds like a better (and, much
simpler to implement) solution compared to building software which is
specific to OSMF and then hacking on support for other servers in a
special build.
In fact I would be very happy if someone from outside OSM - one of the
much-talked-about non-OSM users of JOSM - would set up this build process.
I'll happily help them prepare the patches that get rid of tile
blacklisting.
At this point the patch is simple. Just don't upgrade to the new
version with your change. But as time goes on it's just going to get
more and more difficult.
In any case, whether the crippled version of JOSM is the default or
the special build, it would be best implemented as a build-time or
user-hidden run-time option, than as a separate codebase.
In C syntax, #define CRIPPLE_TO_ONLY_WORK_WITH_OSMF 0/1.
I'm really not interested in wasting my time learning how to build
JOSM, but if it comes to that I guess I could do so.
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: Filter Google from Imagery?
On Thu, Jan 27, 2011 at 6:53 PM, Frederik Ramm frede...@remote.org wrote: I understand that there will be a tiny fraction of users negatively affected by this, but I think it is necessary. We've witnessed a growing number of Google violations in the past year and I would not want JOSM's reputation to be tainted as the editor that makes this easy. Oh please. A tiny fraction? I'm sure there are lots of people who use Google aerials to trace for OSM. We just aren't dumb enough to tell anyone about it. At the very least allow people to use whatever imagery that they want when they're using non-openstreetmap servers. This can then be yet another reason to use a fork, and not OSM. Or do you really want to force us to fork JOSM too? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: Filter Google from Imagery?
On Thu, Jan 27, 2011 at 10:19 PM, Anthony o...@inbox.org wrote: At the very least allow people to use whatever imagery that they want when they're using non-openstreetmap servers. Better yet, just send the user-agent JOSM with every request. Let Google decide whether or not to block access. Any blacklist you devise will be easily defeated anyway. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [OSM-talk] Why I don't use JOSM (was Re: Non-map-based OSM editor)
On Mon, Jan 24, 2011 at 10:43 AM, Anthony o...@inbox.org wrote: If I take notes of which parts I find least intuitive (the parts I have to RTFM about, like how to reopen those right-side toolbarish windows), would anyone be interested in them? Ah ha! That's what the buttons on the left side do. Hmm...I'm not sure how to make that intuitive (*). A divider line between the delete button and the layer button would help indicate that those buttons on the left aren't all drawing tools, though. (*) Other than moving it over to the right hand side, which you probably don't want to do for reasons of space economy. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
On Wed, Aug 4, 2010 at 1:01 AM, Marko Mäkelä marko.mak...@iki.fi wrote: On Tue, Aug 03, 2010 at 08:08:56PM -0400, Anthony wrote: The quality of my own changeset comments is absolutely irrelevant in this discussion; let's assume, if it gives you pleasure, that they are all just That might discredit the messenger, but not change anything about the message. I think that it is important to keep the two separate, the message and the messenger. minor haiti geometry repair fix source typo fix self-intersecting boundary move lake from one relation to other remove forest self-intersection Is that you? Being a programmer and a daily user of version control systems, I share Frederik's view that some effort should be made to write good changeset comments. They can be useful later, say, after several months or years. So do I... I just think it's unrealistic to expect it every time. IMO the job of the software should be to make sure the person knows the software has the ability to use comments. Not to make it difficult for them not to use comments. If we decide as a community that all edits *must* have comments, of a certain length, (and we shouldn't), then that should be enforced in the API. Of the above comments, I think that the first one is questionable, almost as bad as the fixes or adjustments regularly written by some long-time contributors. The remaining ones are descriptive, if the changesets contain just that (e.g., replace source=lndsat with source=Landsat, fix polygons or multipolygons). Nobody is perfect, at least not all the time. :-) Well, I think they're all pretty much useless. As in I can't think of a use case where they would be more than trivially useful for someone other than the editor himself/herself. If *that* is the kind of comment we're trying to put pressure on people to make, I think we're wasting *everyone's* time. Certainly the time of the people who otherwise wouldn't have written such a comment. OTOH, if we're trying to get people to make comments that explain something that isn't evident from the edit itself, then 1) that's clearly unrealistic; and 2) the changes to the software aren't really geared to that anyway (as no technical rules really can be). ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
On Wed, Aug 4, 2010 at 4:26 AM, Frederik Ramm frede...@remote.org wrote: Arguably, the changeset comment could be split up in a number of individual tags. Currently, people use it for different things - they say something about the source, about their method, about where they worked, about why they changed something, or about whether or not the area still needs work... again, as long as we have difficulty in even getting people to describe their edits in *one* tag, it might be too much to ask of them if we asked them to fill in a *number of tags* in a structured manner. I think it would be counter-productive at this time. I'm not in favor of the software asking people to do anything. Rather, its purpose is to provide them a mechanism to do what it is they want to do. That includes informing them of features they might not be aware of. But not being obnoxious about it. Anyway, if you want people to tell you their source, you're better off labeling a text box with provide a source than provide a brief comment. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
On Wed, Aug 4, 2010 at 10:19 AM, Frederik Ramm frede...@remote.org wrote: It is also unrealistic to expect good OSM data edits every time. Still it's good if people try, and good if the software helps them with it. Agreed. IMO the job of the software should be to make sure the person knows the software has the ability to use comments. Not to make it difficult for them not to use comments. The software should also try and make people understand what comments are good for, i.e. why it is good to enter one, and perhaps give some information on what constitutes a good comment if the user is interested. I disagree. This is something which should be easier for non-programmers to edit. And it is something that should be consistent across different editors. You are right if you say there is no metric to measure the usefulness of a comment in software. However, I have just randomly selected 100 comments of less than 10 characters from the current end of changesets, and 100 comments of more than 10 characters, and there was a very noticeable correlation; in my non-representative sample, I found about 70 of 100 long comments useful, and I found about 10 of 100 short comments useful. I think we've already determined that your idea of useful is different from mine. So while the software cannot *ensure* that people place a meaningful comment, it can certainly help with that by reminding the user if it seems likely that his comment is one of the 10 of 100 rather than one of the 70 of 100. I wouldn't be so certain. I think you're more likely to see longer and longer useless comments. I'd rather encourage people who don't feel they can come up with a useful comment to leave no comment at all. And for people who want to leave a not-very-useful comment to use as few letters as possible. It's much easier to filter, that way. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
On Tue, Aug 3, 2010 at 5:22 PM, Ulf Lamping ulf.lamp...@googlemail.com wrote: Am 03.08.2010 18:12, schrieb Anthony: On Tue, Aug 3, 2010 at 4:51 AM, Ulf Lampingulf.lamp...@googlemail.com wrote: I don't think that the change to 10 chars is a good idea. E.g. if I only add a tag to a node, the comment tag added is IMO sufficient but still rings the bell. I'd say a comment of tag added isn't any better than no comment at all. But if I'll add a much longer comment, I'll spend more time to add a meaningful comment than the time to do the actual change. A lot more than the 1% of mapping time that Frederik mentioned earlier. *nod*. Understood. I was more arguing for allowing no comments than for requiring long detailed ones. This isn't like code, where you're usually going to spend hours on a single commit (and where you can reasonably test your change before you commit it). I usually use Potlatch, and I save very often just to avoid losing my work when my browser crashes or when Potlatch decides to corrupt my edit. As such, I usually don't even know what's in a changeset. The changeset generally isn't at a high enough level to merit a comment. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
On Tue, Aug 3, 2010 at 7:34 PM, Frederik Ramm frede...@remote.org wrote: Hi, Anthony wrote: I asked you for your username, because I wanted to see what you consider to be a good changeset comment. It never struck me that you might not actually consider your own changeset comments to be good. I have given a number of examples that I consider good in the discussion over on talk; but I also agree with the examples others have posted there. An ideal changeset comment, in my opinion, would convey the what, where, and why of an edit. The quality of my own changeset comments is absolutely irrelevant in this discussion; let's assume, if it gives you pleasure, that they are all just That might discredit the messenger, but not change anything about the message. I think that it is important to keep the two separate, the message and the messenger. minor haiti geometry repair fix source typo fix self-intersecting boundary move lake from one relation to other remove forest self-intersection Is that you? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On Fri, Mar 26, 2010 at 6:57 AM, Klaus Dietrich kl...@gmx.de wrote: am 26.03.2010 01:41, schrieb Anthony: On Thu, Mar 25, 2010 at 5:50 PM, Paul Johnson ba...@ursamundi.org wrote: On Mon, 22 Mar 2010 01:50:23 -0400, Anthony wrote: In OSM, the way which is tagged highway represents the physical road, right? Centerlines, actually. What centerline? The actual painted centerline (surely not, it's not always there, and it's not always in the center)? The center of the physical road? The center of the lanes of travel? The center of the right of way? Something else? I'm not sure what the correct english term is, maybe axis, but in germany the relevent line is called Straßenachse or Bauachse. See http://de.wikipedia.org/wiki/Achse_%28Verkehrsweg%29 In my understanding, the way tagged highway represents the entire road including the shoulder and is defined by the Bauachse. In my opinion this also means that as long as we don't use areas to map roads, the only correct approach for e.g. landuse next to the road is using the same nodes for both road and landuse. Because if the way tagged highway IS the road and the landuse extends UP TO the road there is no gap between them. I understand what you're saying, and *if* the landuse extends up to the road and there is no gap between them, I think you have a perfectly valid point: to my mind, if that is the case neither situation is correct. You can't get the gap correct and the position correct simultaneously, without using an area to map the road (what Frederik said). Maybe for these situations we are best off using a landuse=highway area. These areas could also be used in situations where the landuse for the highway is greater than the road, but they would be required as an alternative to connecting landuse areas to highway ways. I had pretty much abandoned it (not because I think it's a bad idea, but because I realized that the wiki isn't a very productive place), but see http://wiki.openstreetmap.org/wiki/Proposed_features/highway ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On Mon, Mar 22, 2010 at 12:35 AM, Paul Johnson ba...@ursamundi.org wrote: On Sun, 21 Mar 2010 20:09:43 -0400, Anthony wrote: When I lived in New Jersey it was the same way, and I'd imagine it's the same way in most of the United States. I'd say more research is needed before we call that conclusive. I guess. I'd love to hear of a statewide counterexample. If the right-of-way doesn't extend beyond the road, where are you supposed to walk? (I know of some local situations where there is no walking space on the side of the road, but not of any entire states where this isn't the norm.) At least in Oregon and Washington, street boundaries often extend beyond the street for service access and future expansion reasons (plus the local governments don't deem it particularly fair to tax folks for property extending into the street, preferring to condemn the protruding portions). That's a different question, though. In OSM, the way which is tagged highway represents the physical road, right? I assume this is the case because we tag dual carriageways as two ways, as there are two physically separate roadways, whereas there is generally only a single right of way. Outside of dual carriageways I guess it's ambiguous, unless there's a width tag, in which case, what is it that we're supposed to measure the width of? I can think of at least three different possibilities - the paved surface, the actual lanes used for traffic, and the entire right of way including the unpaved shoulder and/or the sidewalks and/or the [ http://en.wikipedia.org/wiki/Tree_lawn]. Which would you say is correct? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On Sat, Mar 6, 2010 at 7:43 AM, Pieren pier...@gmail.com wrote: On Sat, Mar 6, 2010 at 9:19 AM, Paul Johnson ba...@ursamundi.org wrote: If you go the absurdist route, maybe. If you want to map the landuse of the right-of-way, how about landuse=highway? This has already been proposed. But until everyone is drawing a polygon for the road, we have to accept that the polyline is the road. But the road is not the same as the right of way. The right of way generally (at least in places I'm aware of) extends beyond the road. So, gluing the adjacent landuse to the highway or leaving a space preparing the road polygone are both correct. The second is just more accurate than the first. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
On Sat, Dec 19, 2009 at 9:14 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/12/18 Anthony o...@inbox.org On Thu, Dec 17, 2009 at 7:32 PM, Matthias Julius li...@julius-net.net wrote: My point was that Wyoming *is* a rectangle in a Mercator projection. Well, it would have been if they had surveyed it correctly: http://www.openstreetmap.org/?lat=44.996lon=-110.625zoom=11layers=B000FTF maybe the paper they digitized was waved? I assume that's a joke, but I was unclear so I'll elaborate in case anyone didn't understand. In the 1800s, when they were physically marking the boundaries of Wyoming, they weren't perfectly accurate (up to half a mile off, as Matthias quotes from Wikipedia). The actual legal boundary of Wyoming is how it was physically marked. The legal boundary is the surveyed boundary. ( http://proceedings.esri.com/library/userconf/proc04/docs/pap1718.pdf) I assume OSM has the (approximate) legal boundary. I see the OSM state boundary and OSM county boundary diverge a bit, though, and I'm not sure which is more accurate (I assume the legal boundaries coincide). ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
Spherical geometry allows you to calculate _directly_ on the sphere without using a projection ... you simple use LatLon in radian degrees. True, but it's not really trivial. A rectangle with 89.55°, 90.1°, 89.89°, 90,01° is no rectangle. What's the definition of rectangle in non-euclidean geometry anyway? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
On Thu, Dec 17, 2009 at 5:40 PM, Anthony o...@inbox.org wrote: Spherical geometry allows you to calculate _directly_ on the sphere without using a projection ... you simple use LatLon in radian degrees. True, but it's not really trivial. A rectangle with 89.55°, 90.1°, 89.89°, 90,01° is no rectangle. What's the definition of rectangle in non-euclidean geometry anyway? Here we go: http://www.math.ucdavis.edu/~xqwang/math141/hw7.pdf Turns out Wyoming isn't even a polygon (*), let alone a rectangle. In fact, there apparently are no rectangles on spheres (which probably holds for bumpy oblate spheroids aside from some small exceptions due to the bumpy part). http://www.math.washington.edu/~king/coursedir/m444a04/notes/10-11-Def-of-Rectangle.html (*) In reality. In some projections it is, of course, a polygon. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Geometric calculations and projections
On Thu, Dec 17, 2009 at 7:32 PM, Matthias Julius li...@julius-net.netwrote: My point was that Wyoming *is* a rectangle in a Mercator projection. Well, it would have been if they had surveyed it correctly: http://www.openstreetmap.org/?lat=44.996lon=-110.625zoom=11layers=B000FTF ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
