Re: [Talk-us] Multipolygonizing
Steve, On Mon, Nov 20, 2017 at 04:34:18PM -0800, OSM Volunteer stevea wrote: O> If the reltoolbox plug-in as as powerful as I am beginning to understand it may be (I appreciate the introduction, Gleb), and given my agreement that certain use cases (especially landuse) benefit greatly from multipolygonized boundaries (they do), I actually CAN imagine that the SCCGIS V4 landuse import data (in 2019 or 2020) could become multipolygon. This likely would involve a pre-upload translation of polygon data into mulitipolygon using the tool, then conflation (which has to be done anyway). Except, we upload multipolygons as we delete existing polygons during the conflation-and-upload phase. O> O> I wanted to offer that bright spot of hope to anybody's lingering beliefs that I am "mule-entrenched" in my beliefs that existing polygons are always superior. They are not. They make updates harder, but I think I can get over that, as I can be convinced that "once done, the time investment is worth it" for the future benefits that multipolygons bring. Okay, I will withhold myself from touching polygons in the Santa Cruz County for next couple of years, and let's see how your future experience with SCCGIS goes on. We can get back to this question later in scope of Santa Cruz. Meanwhile, do I understand that my initial understanding of strong consensus against multipolygons in the USA overall was wrong reading? First few emails in the thread made me think so. I'd like to continue working on coastline, and map all remaining SMRs and later maintain them. I also want keep using multipolygons in any regular edits. Are there any objections? -- Gleb Smirnoff ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Multipolygonizing
Kevin, On Mon, Nov 20, 2017 at 04:29:56PM -0500, Kevin Kenny wrote: K> (3) Ease of editing (for better-informed or better-tooled users). At K> least for me, working in JOSM, I find updating a mesh of multipolygons K> with shared ways to be fairly straightforward. Split the ways at any K> new corners, draw any new ways, update the touching regions, delete K> any obsolete ways. Sure, it's a different workflow than the one for K> simple polygons, but for that workflow, I find myself retracing over K> long sets of points, or else splitting, duplicating, reversing and K> rejoining ways. The duplicated ways are difficult to work with, since K> they share all the points, and I have to puzzle over some pretty K> subtle things to understand which copy I'm working with. By contrast, K> the split and joined ways in a shared-ways structure always have K> distinct geometry. Thanks for this paragraph! This was text that was right on my tongue, but I failed to wordsmith it properly. -- Gleb Smirnoff ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Multipolygonizing
On Mon, Nov 20, 2017 at 02:13:44PM -0800, OSM Volunteer stevea wrote: O> Plug-ins that offer "power tools" beyond that? Well, caveat usor. Note that a large part of current JOSM base functionality before was in plugins. So, doesn't make sense to diminish some tool because it isn't in base. Whether some code goes into JOSM or stays as plugin is driven by two things: 1) number of plugin users 2) willingness of plugin author to yield his code to JOSM repo, meaning disown his code. And for many people that also means lose commit access to their code. -- Gleb Smirnoff ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Multipolygonizing
On Mon, Nov 20, 2017 at 11:43:34AM -0800, Mark Wagner wrote:
M> > (I couldn't for the life of me figure out how to add a way to a
M> > relation!)
M>
M> Select a way currently part of the relation. Shift-click on the way
M> you want to add. Select "Update multipolygon" from the "Tools" menu,
M> or hit Ctrl+Shift+B. Simple.
M>
M> Of course, this only works for ordinary relations. If the way you
M> clicked on is shared by two or more relations, you need to go
M> through the far more complicated method of playing with the
M> relation-editor dialog.
Or use "reltoolbox" plugin, where there is a notion of current
relation, and while you got your relation selected as current,
adding or removing objects to it is clicking "+" or "-" icon on
the sidebar, having object selected. For multipolygons it will also
set "outer" or "inner" role automatically.
--
Gleb Smirnoff
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Multipolygonizing
port updates) and whatever small cost you believe you are saving in either elegance or the amount of data in the map is very much outweighed by "simpler is better." Simple, while it may share a few nodes or overlap some ways, isn't wrong, it is far easier to understand and maintain, especially for novice mappers, and ESPECIALLY when updates to imported data essentially rely on the "simple polygon" paradigm which already works so well in our map. O> O> With respect, O> SteveA O> California O> O> O> Douglas Hembry <doughem...@hotmail.com> writes: O> > Greetings everyone, O> > I've just had a short changeset discussion with mapper glebius prompted O> > by changeset 46612750 "Properly multipolygonize Monterey coast line". My O> > understanding is that the map of this stretch of coastline has been O> > restructured to avoid adjacent ways that share nodes. Accordingly, only O> > a single way ever connects any set of nodes, and the single way O> > participates, if necessary, in multiple relations. A result of this is O> > that in a high density area like downtown Monterey Bay many small areas O> > like building footprints or pedestrian areas are defined as distinct O> > multipolygons, with several ways (outers) making up the outline. An O> > example at: O> > O> > https://www.openstreetmap.org/#map=18/36.61726/-121.90045 O> > O> > (look at Hovden Way near the top, or the outline of 700 Cannery Row, O> > further down near Bubba Gump, comprised of seven outer ways) O> > O> > glebius believes that this approach (with the help of the reltoolbox O> > JOSM plugin) is easier and less error-prone than having multiple simple O> > closed ways (eg, a building footprint and an adjacent pedestrian area) O> > sharing a set of nodes on their adjacent boundary. . (I hope I'm O> > representing this accurately, glebius will correct me if I'm getting it O> > wrong). O> > O> > In my limited experience I've never encountered this before, and at O> > first sight I'm not convinced, particularly when considering future O> > maintenance. I told glebius that I wanted to find out what the O> > community thought. Is this just one more valid optional way of mapping? O> > To be recommended for adoption if possible? Or to be avoided? Thoughts? O> O> And Rihards <ric...@nakts.net> writes O> > not an authoritative opinion : it's terrible. mapping contiguous areas O> > as multipolygons results in data that is extremely hard to modify (think O> > splitting landuse from a building) and is more than a minefield for newbies. O> > O> > personally, i either redo these as separate ways when i have the time O> > (original authors do not object as they have went either mad or out of O> > energy after working with multipolygons too much), or give up and leave O> > the area outdated - i don't have the skills to maintain that. O> O> -- Gleb Smirnoff ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Proposal: winter roads
Dave, On Sat, Oct 09, 2010 at 12:13:14AM +0100, Dave F. wrote: D The wiki page describes subjective information. D D Unless it's actually closed by authority don't say it's impassible. For D instance in defense of your argument that it's impassable you say the D average speed is 0.5km/h. This comment proves the it *is* passable, just D very slowly. No this one is not passable, and vast majority of other winter roads are not passable, too. Let me explain again: first, the photo is taken at a piece of winter road that is reachable by 4x4 vehicle. Evidently, I can't make a photo of a vehicle at a place where vehicle can't get to. If I walk there by foot, and make photo w/o vehicle on road, the photo won't tell anything: an untouched muskeg swamp looks like a meadow. Dmitri has added another photo of winter road, it demonstates better the terrain: http://wiki.openstreetmap.org/wiki/Proposed_features/surface:winter_road I didn't put that photo first, since composition doesn't include cutline going to horizon, no road seen. So, winter road may contain sections driveable by 4x4 in summer, but in most cases entire transit via winter road is not possible, due to river crossing, long on-swamp sections, etc. Second, 0.5 klm/h means unpassable if road is a distant one. The road photo is taken at is 150 klms long. Vehicle can't carry enough fuel to travel 150 klms at 0.5 klm/h speed. And no winch will survive that. Concerning authorities: in spring, when road starts to melt, but weather is still very cold, some roads are closed administratively, because entering them is a risk of death. In summer they are just abandoned, 4x4 fans may enter them and try theirselves. D The reason the vehicles in the picture needs winches is because they're D *not* suited to the terrain, not that the terrain is impassible. D D A colleague of mine has a Ural truck that *could* travel this way. D D *http://www.4wdonline.com/Mil/Ural/PiCs37/375D.jpg* Ha-ha! Believe me, Dave, Urals never ever drive winter roads in summer. This is what any Ural driver from northern Russia will tell you. A light 4x4 weighting 1.5 - 2.5 tons has more chances in swamp than Ural, whose empty chassy weight over 8 tons and average vehicle weigths over 11. And you can see on the second photo that we reached place, where deep ruts from Ural end, and untouched swamp begins. D As I said before, please don't tag ways based on your limited D experiences, tag them on *factual* information, leave subjective D decisions of whether they're *able* to the people traveling that way. Yes! This is what we are going to do. We want to mark winter roads as winter roads, and users may decide theirselves whether they are passable or not: look at satellite image, seek for swamps and river crossings and may be try theirselves. If you just dislike the word impassable in wiki page, we can transform it probably impassable or smth else, you prefer. And if you do a transit via long winter road in summer, on a road-legal vehicle, I owe you a box of beer. :) -- Totus tuus, Glebius. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposal: winter roads
Hello, the fact the road is a winter one, is an important thing that should be marked on map. http://wiki.openstreetmap.org/wiki/Proposed_features/surface:winter_road -- Totus tuus, Glebius. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal: winter roads
Dave, On Fri, Oct 08, 2010 at 02:50:22PM +0100, Dave F. wrote: D the fact the road is a winter one, is an important thing that should be D marked on map. D D http://wiki.openstreetmap.org/wiki/Proposed_features/surface:winter_road D D This type of tag is based on subjective opinions which is bad D information to put in OSM. No. It is not based on subjective opinion. Winter road is an official status of a road in Russia. It is the way it is marked on other maps. The road is officially closed, when it starts to melt. And it is officially serviced during winter. Please refer to wikipedia article. Winter road is not a subjective opinion. D For instance the second photo' is labeled as impassable. Surely it is passable - you see two vehicles successfully passing it :) This is just a photo I made, where we could get to. But the road continues, crossing 5 meter deep swamps and rivers. What is your version for tagging this road, concerning that it is official way to a small town and is drivable at high speeds on regular vehicle in winter? Some parts of winter road may be passable in summer, some may not. Their condition in summer is unknown and not guaranteed, their condition in winter is guaranteed. This is special property of road that should be marked on map. D In fact, to me, it seems the first photo' is the more impassable as when D snow is tamped it forms ice. Slippery doesn't mean impassable. -- Totus tuus, Glebius. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Abnormal votings on military objects in RU wiki part; PocketGIS madness
Hello, Let me followup on this topic. I am Russian citizen and I didn't want this problem to appear on this list. I hoped that we could solve it ourselves. I second all the information that Komяpa provided. Also, all the arguments that were provided to Kirill by Frederik, John, Liz and others have already been told dozens of times in our forum and on our IRC. That is: - if you don't want data in PocketGIS, then just do not export it - maps published by unlicensed parties are not legal *generally*. this is not related to militarys depicted. - industrial or barrier is not truth on the ground The argument about China is new, however. Thanks. -- Totus tuus, Glebius. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] tagging tyre/tire services?
Hi! Didn't find in Map Features page how to tag a service that can mount, unmount and repair motorcar tyres. This is a quite important POI for a car traveller. Looking at tagwatch, I've found a small usage of service=tire, 55 instances in Europe. Let's define an official tag for this and document it in Map Features page. An advice from native English speakers is required: which word is better for tag key: service or shop? which word is correct for tag value: tire or tyre? -- Totus tuus, Glebius. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
