Re: [Talk-us] Recent Trunk road edits
On 28/09/2020 12.27, Paul Johnson wrote: On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke wrote: On 28/09/2020 11.42, Jack Burke wrote: I'm willing to bet that most OSM editors who drive on either of those two will think "this is a great freeway, just with occasional traffic signals." That's an oxymoron. Freeways are, by definition, limited access (no crossing intersections, period) and do not have (permanent¹) signs or signals to halt traffic. IMNSHO, if it has traffic lights, stop signs, or the possibility of vehicles suddenly driving *across* the way, it isn't a freeway. True, but highway=trunk can mean either expressways (think like freeways that have some or all at-grade intersections; note that having freeway-style ramps in between junctions doesn't make it a highway=motorway), or single-carriageway freeways. In both cases, they tend to get built as an incremental case to building a full motorway, but are not yet motorways. We're getting dangerously into the territory of words with ambiguous meanings. Note https://en.wiktionary.org/wiki/freeway, especially the first definition. Note also my point was about "freeways", not highway=trunk. Many in the US would consider "freeway" and highway=motorway to be nearly synonymous. (The "nearly" is when we start talking about non-interstate limited access.) I did later state that limited access is *not* a requirement for highway=trunk. Also, Jack has clarified his usage as "artistic"... That's not to say there aren't non-interstate highways that meet these definitions. But... is it a highway=trunk? *I* don't see where the wiki excludes the possibility. (It does, however, seem to me that only *actual* interstate freeways should be highway=motorway in the US.) That's not true at all... Citation needed. I don't think that's been established (although we're getting pretty off-topic...). The *converse*, sure (interstate =/> motorway), I'll concede that. [...] the transitions to where an interstate ends and it continues as another kind of highway past the last exit before a junction, I would question whether those should be highway=motorway. (Yes, I'm looking at https://www.openstreetmap.org/way/98245488 and surrounding, possibly as far north as https://www.openstreetmap.org/node/41485037.) -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Recent Trunk road edits
On 28/09/2020 11.42, Jack Burke wrote: I'm willing to bet that most OSM editors who drive on either of those two will think "this is a great freeway, just with occasional traffic signals." That's an oxymoron. Freeways are, by definition, limited access (no crossing intersections, period) and do not have (permanent¹) signs or signals to halt traffic. IMNSHO, if it has traffic lights, stop signs, or the possibility of vehicles suddenly driving *across* the way, it isn't a freeway. That's not to say there aren't non-interstate highways that meet these definitions. But... is it a highway=trunk? *I* don't see where the wiki excludes the possibility. (It does, however, seem to me that only *actual* interstate freeways should be highway=motorway in the US.) Related: if it's I-## or I-###, shouldn't it be a highway=motorway, period? (Unless those, for some reason, are ever *not* freeways?) (¹ In case of active construction or accidents, all bets are off.) -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] Changeset Comments Copyright
On 22/09/2020 17.43, GITNE wrote: As far as I can tell no document covers changeset comments either explicitly nor implicitly. The Contributor Terms state that “…contributing data and/or any other content (collectively, “Contents”) to the geo-database of the OpenStreetMap project (the “Project”)” is explicitly limited to contributions to the geo-database (map database). As far as I can tell changeset comments are not part of the OSM's geo-database. Changeset comments themselves do not contain any geo-data, they merely reference a changeset. The changeset contains geo-data and is what actually becomes part of the geo-database. Thus naturally changesets are covered by the Contributor Terms but not changeset comments. Consequently, it should be fair to assume that the copyright to changeset comments remains with their respective authors. However, since changeset comments are apparently neither explicitly nor implicitly covered by any agreement or license, it should be also fair to assume that by the act of creating comments on OSM's website commentators do grant copyright to the OSMF, though limited in scope. I'm pretty sure there is no *copyright* granted to OSM. Likewise... It is fair to assume that the scope is limited to the production or quality assurance of the map. I think that given this situation it should be very difficult to argue that commentators implicitly grant copyright to any other party than the OSMF, publish comments into the public domain, or for any extended purpose. Anyhow, imho either way it would not be wise—today's more fashionable word here would be “smart”—for the OSMF to grant changeset comment copyright to others. I am ***almost certain*** that OSM does not grant *copyright* to other parties. I'm pretty sure the term you want is *license*. This may sound pedantic, but this is an area where getting your terminology correct can matter, and there is a ***huge*** difference between granting "copyright" (assigning *total ownership and all rights* to another party) and granting "license" (extending *limited* rights to another party while retaining ownership). As far as I know (and can tell from https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms), contribution to OSM are *not* subject to copyright assignment. -- Matthew ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] place=neighborhood on subdivisions?
On 23/09/2020 00.52, Paul Johnson wrote: In terms of Seattle, I don't think Ballard or Magnolia are a suburb. They're more of a neighborhood, both subordinate to Seattle. I admit this threw me at first also, but read https://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb. To wit: "OSM's usage of 'suburb' is different than that used by North American English, where a suburb is 'an area, often residential, outside of a central city'." In the US, we're used to a "suburb" being a separate town, village, or even city that is associated with a large city (New York City, Chicago, Houston, Los Angeles, Seattle, etc.), but that's not the definition that OSM uses. As I understand the wiki, the Seattle usage is correct. -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
On 31/08/2020 15.56, Kevin Broderick wrote: First, I'd like to point out that this discussion started off with the question of removing "access=private" from Amazon-logistics-mapped driveways. I still maintain that the mechanical edit would be a good thing, because the tagging as added is based on an assumption that service=driveway implies access=private, which (a) isn't 100% accurate, and (b) adds the appearance of more detail in the database without actually adding any value (i.e. if it is a safe assumption, then adding the tag is superfluous; if it isn't, then adding it is potentially misleading). Second, I'd like to point out that there *are* driveways in New England that are actually public right-of-ways. On a related note: I use service=driveway (for lack of anything better) for access ways to parking lots that don't have parking spaces (hence, not service=parking_aisle). These are likely *not* public right-of-ways (the lots themselves are usually "private"), but they are also certainly not access=private. So, no, service=driveway should *not* imply access=private. If anything, lacking other information, it should imply access=yes just like it does on any other way, and I suspect routing engines route accordingly. This, BTW, is a large part of why we're having this conversation in the first place. The problem with overusing access=private is that we're effectively teaching routing engines to ignore that, which makes such tagging much less useful. -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
On 31/08/2020 11.19, Greg Troxel wrote: What I objected to was not "that is your opinion; many others disagree" but "that is your opinion but *no one else* sees it that way". If you didn't really mean that, sorry for overreacting. Fair enough. I probably should have said something like "my understanding is that this is contrary to the community consensus". It's always possible that what appears *to me* to be the community consensus looks different to others. -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
On 31/08/2020 10.54, Greg Troxel wrote: Matthew Woehlke writes: *You* may see it this way. The rest of the community does not. A declaration that every other member of the community disagrees is unreasonable. I'm not sure if this is directed at me or at Mike. If at me, I'll point out that the fact we're having this conversation in the first place is because someone strongly disagrees with residential driveways being access=private "by default". Nor is it the first time I've encountered that opinion. Honestly, my initial opinion on the matter was closer to Mike's, but others told me I was wrong. B) private shopping centers where the public is welcome, to shop. (access=customers, mostly) C) private land where use is known acceptable (access=permissive) Even this is not clear. *My* understanding is that most businesses are closer to access=permissive, with access=customers referring more to places that are explicitly signed as "customers only". In most shopping centers, for example, it seems acceptable to go there just to walk around even with no intention of purchasing anything. (At least, I know that people do so...) -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
On 31/08/2020 10.18, Mike Thompson wrote: On Mon, Aug 31, 2020 at 7:46 AM Matthew Woehlke wrote: The objection is that access=private currently *has* an understood meaning, and that meaning is *no* access without permission, not what you described above. Sounds like my driveway. If you are using my driveway without my permission, either implicit (e.g. delivering a package) or explicit, I am going to ask you to leave. I think you are conflating whether something is "not allowed" with "can be prosecuted as a crime." I think *you* are conflating implicit permission and explicit permission. access=private as I understand the general community consensus to be means no access without *explicit* permission. No access without *implicit* permission is closer to access=destination... but note I said "closer to". We don't seem to have something that exactly means "no access except by *implied* permission". -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH
On 30/08/2020 10.00, Greg Troxel wrote: "Alex Weech" writes: Another thing I just thought of over breakfast, in New Hampshire by default private land has public access, and landowners have to post that trespassing is not allowed. It could be that that's a quirk of this part of the world, and other places don't have a posting requirement, which is why there's some cultural disconnect. It is likely the same law has Mass, but I think you have the details of "public access" subtly wrong. I think the law says: Being on someone's land without permission is trespassing, but this is not a crime. If it is posted, or you have been told, then it is a crime. From that, one can not conclude that "by default private land has public access" in the OSM sense. You can only conclude that "if you walk on it you are not committing a crime". In OSM, access=yes means "the public has a legally-enshrined right of access", so not only can you go there, but other people cannot tell you not to go there. This notion of a right is foundational to access=yes. I agree we need a new tag. As I see it access=yes legally-enshrined right of access, like a public street. (Also used for private conservation land where the landowner invites the public, even though technically they could change the rules.) Perhaps shopping centers, even though not a right, it's close in practice. Essentially always in truly public places. access=permissive no *right* of access, but generally understood that the landowner does not object to typical use. Often on trails not near houses that cross private land, but without an easement. Basically can only be added by a local because it is essentially never signed. access=private There is no right of access for random people. There is no social expectation that it is reasonable for people to go there for for arbitrary purposes. (For example, an actual neighbor coming to introduce themself, etc. is ok.) This is the default assumption for driveways in New England - basically actual neighbors behaving in an actual neighborly way that they wouldn't mind someone else doing at their house is ok, deliveries ok, maybe gathering signatures for ballot access ok, and pretty much anything else not ok. *You* may see it this way. The rest of the community does not. access=private sign:no_trespassing=yes Further means there is a no trespassing sign. (we already have a way to map gates.) What is the actual problem with other people's driveways being marked access=private on the map? yes, driving on is usually technically not illegal, but unless you are going there because you were invited for have a reason they'd approve of, it's basically not ok. The objection is that access=private currently *has* an understood meaning, and that meaning is *no* access without permission, not what you described above. I don't think it's reasonable to change that definition, as it would invalidate huge amounts of the map. If access=destination is not acceptable, perhaps we need a new category. -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[OSM-talk] Mapping feature ideas (was: Funding of three infrastructure projects)
On 04/08/2020 11.08, Martin Koppenhoefer wrote: On 4. Aug 2020, at 16:26, Matthew Woehlke wrote Obviously, this would all almost surely be a temporary mode (maybe it persists as long as JOSM is open, but isn't uploaded), but since you usually draw once, that would be fine. (Bonus points if JOSM could automatically recreate constraints for ways that don't have any. It shouldn't be hard to guess equality, perpendicular and colinear constraints, at least.) rather than guessing, I sometimes have wished there had been a way to actually store relationships (geometric) in the data, something like these buildings all align their front facades, or this door (or building position) is aligned to this street axis, etc., so when people moved the street, the building would move as well. Would become very complex if it would be used extensively (basically you might move the whole city by moving a node, or it could lead to unresolvable constraints, etc.), so I think it’s not gonna come. Just accept some fuzziness ;-) Sure, I can see the use. I was thinking in terms of things that can be done without schema changes. Besides the troubles of trying to resolve an overconstrained system (something I've run into with FreeCAD for systems that are probably much more simple than what OSM might become!), another issue is that editors that don't support the constraints — I'm looking at iD, mostly because I shudder to think of the complexity and performance of implementing a solver in a web browser! — will tend to break them often. So, I'm not going to hold my breath ;-). People are overrating rectangular buildings anyway, they might look more correct than a freehand approximation, but they typically aren’t (too short, too long, too wide, wrong angle not parallel to the street, not parallel to their neighbors, etc.), sometimes resulting from misinterpretation of aerial imagery and conscious or unconscious generalization (representing with a single rectangle what in reality is a rectangle with an oriel or a cutting or some other added shape). Sure, I've seen some overly generalized buildings. I tend to model with more detail. (See for example https://www.openstreetmap.org/way/44931534, which is also a good example of where more constraints would have been useful; there are at least three axes of symmetry, and the four corners at the extrema of the longer axis *realy* look like they line up.) Still, we *do* tend to build things with right angles, so right angles are very often correct. At least for buildings. (Roads can easily get more sloppy.) And sometimes a lack of diligence (e.g. when a building is on the crossing of two roads which aren’t orthogonal, it is not unlikely that the building isn’t orthogonal either, and it might be easily visible in the imagery, but if you only have a hammer, you might be tempted to use it for the screws as well). Well, that's a user problem :-). I've also run into many, many instances of things that seem like they *ought* to line up, but if aligning is noticeably different from the imagery, I won't force it. Most of what I'm picky about is within individual buildings, or stuff like aligning parking aisles in the middle of the spaces because it renders better and the way is (since it's a line, not an area) necessarily an approximation anyway. Conversely, I'll get a little more "sloppy" with placement, because I generally trace roof lines and then try to shift the shape to compensate for parallax and my best guess at how much the roof overhangs the wall. Again, see the previously cited example and compare how it lines up with the corners *on the ground* and not the roof line. See the adjacent https://www.openstreetmap.org/way/830822584 for an even more pronounced example; this one is straddling separate images that were stitched together, so there is a discontinuity in the parallax going through the middle of it. Constraints actually *help* here because I can make a reasoned guess at stuff like "these walls probably line up" and use that to try to deduce the actual shape when the imagery is messed up. Of course, a lot of this will depend on the quality/resolution of the imagery available. On the US East Coast, MapBox is very high resolution, which help significantly. Trying to map to the level of detail I'm typically doing is probably not possible with lower resolution imagery. -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 04/08/2020 08.10, Martin Koppenhoefer wrote: On 4. Aug 2020, at 13:58, Matthew Woehlke wrote: but I would practically *kill* for JOSM to have FreeCAD's suite of sketch constraints ;-). you’re aware that there are sketch constraints for configurable angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle display becomes green) Yes. They're better than nothing, but nowhere near what I'm talking about. As an example, consider the attached simple FreeCAD sketch which is roughly representative of some buildings I've mapped recently. The dome in front is centered (segments on either side constrained to be equal). The "wings" in back are symmetrical. It's *possible* to do this sort of thing in JOSM with a lot of care and by building part of the geometry, then constructing a bunch of "scratch" geometry in order to construct a symmetry line, then doing a copy, paste in place, mirror, reverse, stitch the parts together... but God help you if you make a mistake and have to start over. In FreeCAD, you just slap on some equality constraints, angle constraints, parallel constraints, etc. and then you can *move* any of the nodes and everything else will update to preserve the applied constraints. (The one things it's missing that would be helpful is a *colinear* constraint; you have to simulate that with parallel and coincident constraints using "construction" lines; those are the blue ones. A colinear constraint could eliminate the need for those construction lines.) This is the major difference, though. In JOSM, constraints only apply when you initially draw something, so if you get it wrong, you have to start over. In FreeCAD, they're a dynamic system; if you get it wrong, just nudge it and the whole thing updates *while preserving your constraints*. Oh, and *arcs*. The ability to define a segment that should be a perfect arc, and optionally make it tangent or perpendicular to its neighbors, would be a major boon. Again, I can fake it with a bunch of scratch construction, but if it's wrong, I have to start over and hope my next guess is better. In FreeCAD, just drag the end points until it looks right. Then there are distance constraints, which would be incredibly useful if you're mapping something with known dimensions. Seriously, give FreeCAD a spin. It's pretty awesome for this sort of relatively simple 2D stuff. Also look at some of the buildings I've done recently; the symmetrical ones don't just *look* symmetrical, they *are* symmetrical (within the limits of JOSM's abilities). I've also done a lot of stuff like roads that are perfectly centered in between parking spaces, groups of aligned buildings that are *actually* aligned, and whatnot. It's do-able, but it would be *s* much easier with FreeCAD-style constraints. Obviously, this would all almost surely be a temporary mode (maybe it persists as long as JOSM is open, but isn't uploaded), but since you usually draw once, that would be fine. (Bonus points if JOSM could automatically recreate constraints for ways that don't have any. It shouldn't be hard to guess equality, perpendicular and colinear constraints, at least.) -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 04/08/2020 05.30, pangoSE wrote: On older hardware like my 2 core 2ghz laptop iD is slow. Loading while saving an edit is slow, while JOSM is always fast and saving does not close the edit view so you can continue without waiting for a browser to load the iD editor again which is also slow. I want your JVM :-). I have yet to encounter a Java program (including JOSM) that isn't sluggish. (JOSM could be worse, but it's nowhere near what I'd expect from a well-written *native* application.) Matthew Woehlke skrev: (3 augusti 2020 16:14:13 CEST) (¹ iD can 'square up' individual nodes and does a passable job with *mostly* orthogonal shapes with the odd 45° angle. There are ways to work with those in JOSM, but generally speaking if you try to square a shape with a single 'wild' node, JOSM turns the whole thing into a hot mess.) This sounds like a bug. Have you reported it? Ah... I partially retract that. I think the problem is that I'm trying to make it work more like iD which permits *selective* squaring. I probably have some nodes selected that's making it go bonkers. Really, this is a missing feature; I want a way to either square up individual nodes, or only angles that are within some delta of 90° already (and maybe to snap other angles to e.g. 45°). Meanwhile, I've gotten better at creating scratch geometry to help with construction, but I would practically *kill* for JOSM to have FreeCAD's suite of sketch constraints ;-). -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2
On 02/08/2020 06.05, Simon Poole wrote: Extending this a bit further, you could just as well say, given that all current and actively maintained general purpose editors require 1-2 FTEs, the OSMF should simply block all non-iD editors and tell the developers to either work on iD or go home. For OSMF *funding* purposes this might happen, but telling volunteers what they should or should not volunteer to work on should be a hard no-go. iD is branching out in to more and more niches, reducing the breathing space for anything else massively and other editor use has effectively been stagnating for a long time. While people will automatically try to start listing special use cases that can "only" be done with editor XX, the problem is that these are special cases and unlikely to be worth spending a couple of $100k on per year (virtually or real) for the small number of users that will remain as iD gains more and more features. There are a few things iD does "better" than JOSM¹, but it is *far* from feature parity... and one use case which I consider *absolutely essential* before it could be considered a JOSM replacement is the ability to load and save local files (notably including shapefiles and geotiffs) and work on non-OSM layers... and I'm not sure that will ever happen. JOSM isn't "really" an OSM editor, it's a GIS tool that "happens" to have really good OSM integration. (Note also that these features are *mandatory* for doing imports from other GIS data.) I've been using JOSM a lot lately, and AFAIK iD is quite some ways from matching even some of its more "basic" functionality. Angle constrained ways, lane view, way smoothing features, ability to mirror content (symmetry), and more. Relations are *much* easier in JOSM. Heck, just *selecting things* is much easier. I'm not saying iD is *bad*. It's a very nice editor *for its capabilities*. It's great for making *small* changes or introducing someone to OSM editing... but there are a lot of use cases still where JOSM is just a far superior tool. Maybe in *5-10* years that will change, but I'm not going to hold my breath on it overtaking JOSM in 1-2. (¹ iD can 'square up' individual nodes and does a passable job with *mostly* orthogonal shapes with the odd 45° angle. There are ways to work with those in JOSM, but generally speaking if you try to square a shape with a single 'wild' node, JOSM turns the whole thing into a hot mess.) -- Matthew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-legal-talk] Disclaimer regarding data in Virginia (US)?
OSM surely incorporates data in Virginia which was not prepared by suitably licensed entities (per https://law.lis.virginia.gov/vacode/title54.1/chapter4/section54.1-402/). According to Virginia law, OSM must therefore display the following notice: Any determination of topography or contours, or any depiction of physical improvements, property lines or boundaries is for general information only and shall not be used for the design, modification, or construction of improvements to real property or for flood plain determination. Is this notice already displayed somewhere? If not, where should it be displayed? (Note: I came across this while considering PWC GIS data for import; n.b. https://wiki.openstreetmap.org/wiki/Contributors#Prince_William_County.) -- Matthew ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] Labeling forestry service roads/tracks
On 19/07/2020 18.47, tj-osmw...@lowsnr.net wrote: Editing in Boundary County, Idaho in the Panhandle, I've been extending the forest landuse area around Bonners Ferry and have come across a difficulty in classifying forest roads. It seems that many have been automatically imported and have highway=residential, which is just plain wrong. FWIW, this seems to be endemic in TIGER data. I often suspect that everything that isn't a primary or secondary gets marked "residential". For roads that appear metalled (paved) and/or access mines, quarries, communication towers etc. I label highway=service, for roads that are unpaved or sometimes seem to almost fade out I label highway=track. For roads that appear to be public access (e.g. to go to a lake) but are obviously even more minor than tertiary roads I label highway=unclassified. Sounds about right, at least for the first and last. I'm less certain about "highway=track". (Not saying it's *wrong*, just that I don't know, vs. the others which sound correct to me.) Well, modulo Mike's comment; where I've been using "highway=unclassified" is for things that really don't look like service roads (e.g. that connect to other road networks) but likewise are clearly not residential. For example, https://www.openstreetmap.org/way/20453748. TIGER seems to be at best very coarse, at worst fictional. Yup, that is known to be the case. As I understand it, TIGER was created mainly for census-taking, and so as long as someone on the ground could look at the map and figure out more or less how to get to the houses on a particular road, that is "good enough". Positional accuracy in that respect isn't nearly as important as *connectivity* accuracy, which partly explains the quality, but even connectivity can be dodgy. (As you noted, it's not unusual to be missing entire roads, or to have roads that don't really exist, and that's *before* we start worrying about changes that have happened since.) -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-talk] private or not, USA ?
On 16/07/2020 21.06, Steve Friedl wrote: On 16/07/2020 20.58, 80hnhtv4agou--- via Talk-us wrote: Are wi-fi passwords and the IP number of a hot spot, located in MC Donald, burger-king, Starbucks, Answering a different question than what you asked: they don’t belong in OSM, so any other answer is off topic. ...and in addition, yes, they are private. Such AP's are usually for customers only; said establishments will likely be very annoyed if you go around publishing their passwords. It may even be illegal to do so. **DO NOT** add such information to OSM. -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports-us] Interested in importing address points in New York State
On 16/07/2020 00.44, Skyler Hawthorne wrote: Reading up on the import guidelines, I can see that the license is important. However, I am not able to see anything that explicitly states one way or another what kind of license the data sets are distributed under, and this whether or not it is compatible with the ODBL. Hello again! Great to see someone else working in my neck of the woods! If the site doesn't state clearly (an issue I had with Prince William County, VA, which I have been working on for job-related reasons), I would recommend contacting the data issuing agency. I see it's a .ny.gov site, so it's almost surely legitimate (plus it's hard to imagine someone making the effort to set up a scam site with enough content to not be obvious). There are some form letters you can use to ask if the data is available under a compatible license, or you can just ask them to clearly indicate the license *or if the data is Public Domain*. In my experience, it may be helpful to ask up front for the contact to clearly state if the data is or is not PD. As a disclaimer, I do this in my free time, which is in short supply, so progress on this would likely be slow. However, I would love if everyone could just search for any address and find it. As someone who recently went looking and discovered that his former residence "doesn't exist" in OSM, I for one will be most gratified to see any improvements in the area :-). -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] local copyright law on government data and OSM license
On 15/07/2020 21.16, Erwin Olario wrote: Recently, some edits in the country came to the attention of the community When you say "the country", what country are we talking about? I guess from context you mean "the Philippines", but you really ought to specify. (I've been editing a bunch of stuff in PWC, Virginia, USA based partly on government data which I have been assured by the issuing agency is Public Domain. I *hope* you aren't talking about me, but it's really unclear.) -- Matthew ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] Importing data for Prince William County, VA
On 13/07/2020 17.46, Mateusz Konieczny via Talk-us wrote: Jul 13, 2020, 20:29 by mwoehlke.fl...@gmail.com: It is still required to use a separate account for manually audited changes? Is it going to be "by comparing dataset X and OSM I found places to map roads that I added using aerial images"? Or more of "manually copied and verified geometries from external dataset"? So far, I've done a bunch of stuff (on my own account) using the GIS data more as a supplemental reference layer, i.e. I haven't *technically* imported anything (but *have* hand-added some roads and other features and hand-edited others). At some point, I am likely going to need to do a mass import of buildings, and that almost certainly *will* be an import. -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=private on driveways
On 14/07/2020 09.44, Alex Hennings wrote: Regarding: a driveway to a house should not be tagged access=yes because a no trespassing sign cannot be seen. That is a complete violation of verfiability, becuase the mapper has zero evidence that access should be yes. *Given our defaults, no access tag is equivalent> to that.* You're saying *omitting* a tag violates *verifiability*. That doesn't compute. Requiring tags to be verifiable with evidence specifically means the opposite of that. But that might get us closer to the source of disagreement. You and I interpret a *missing* access tag differently. *You read a missing access tag to mean access=yes*. (Is there documentation to support that somewhere? or... why do you think that?) That's how iD represents it. There is, of course, a solution to this... propose a new value with the appropriate semantics. The (possible) problem with having access implied by service=driveway is that a lot of access roads to stores/businesses/offices are also service=driveway... although I suppose you could argue these have the same semantics; you shouldn't be using them unless you're actually going to the location to which they provide access. (Which isn't to say that no one ever violates this...) -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)
On 13/07/2020 15.16, Kevin Kenny wrote: I'll confess to having perpetrated a fair number - at a time when I didn't know better. Likewise. That said... A few things, though: The immediate curtilage of a house is presumed to be private; at least in the US, one does not drive or walk directly up to someone's house without having business there. (Someone making a delivery, obviously, has business there.) ...this seems to be the definition of access=destination? Is that the recommended way to tag residential driveways? I haven't had any trouble getting OSMand to navigate to a house on a road marked `access=private`. It pops up a warning that my destination is on a private road, and asks whether it's OK to route over it - and then does so happily. My car does this, and doesn't even ask. It just warns me that "this route uses private roads". I generally assume that's talking about the final leg and ignore it. I'm perfectly willing to believe that overzealous application of 'private' breaks _some_ routing engines, but 'breaks routing for everyone' is a bit hyperbolic. Yup. That said, it does seem like access=destination is more correct for ways that aren't explicitly access-restricted? -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing data for Prince William County, VA
On 13/07/2020 14.22, Mateusz Konieczny wrote: If you are staying from manually reviewing and editing based on this new data, aerials and current data it should be perfectly fine as long as you actually review what you add. For now, yes. For buildings (later, and I'll probably ping y'all again), I expect that to be more automated, but probably still manually reviewed. It is still required to use a separate account for manually audited changes? -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing data for Prince William County, VA
On 13/07/2020 13.44, Mateusz Konieczny via Talk-us wrote: Are you sure that it is in public domain? It is according to the government POC. https://lists.openstreetmap.org/pipermail/imports-us/2020-July/000954.html -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing data for Prince William County, VA
(Repost to talk-us also.) On 13/07/2020 10.44, Matthew Woehlke wrote: I am working on a project that wishes to tentatively use OSM data from Quantico and possibly surrounding areas. Unfortunately, OSM is somewhat lacking in this area, especially within Quantico itself. I would like to import data from information provided by the county¹. To start with, I would like to use the country-provided roads to improve road shapes and fill in missing roads (for now, manually, probably using Merkaartor, and checked against available aerial imagery). Eventually, I want to add buildings and maybe anything else that seems useful. Being data generated by an agency of the US government, the source data is Public Domain (verified via the contact information provided on the site). Comments/concerns/objections/suggestions? (¹ https://gisdata-pwcgov.opendata.arcgis.com/) -- Matthew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
