Re: [Talk-us] Way to message a bunch of users at once?
Jonathan Schleuss writes: > Is there a way to email multiple users at once? Yes and no. I created a hack to mail to geolocated OSM users, but I feel disinclined to share that. Of course the board of directors can authorize the sysadmins to send bulk email, but that happens only rarely. I designed a system for communicating with users, but never implemented it. Since it's opt-in, it's not spam. The idea is simple: allow people to receive notices posted via the OSM user interface to a particular lat/lon. They do so by adding one or more bounding boxes for their areas of interest to their OSM profile. If the notice's location falls in their bounding box, they get the notice in their OSM Inbox. Not hard to implement if you know or want to learn Ruby. Neither of those applies to me. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Way to message a bunch of users at once?
I'd really not see OSM messaging turn into a vehicle for spam. I know that's not what you're doing, but a multi-message facility would surely be abused that way. The best thing I can think of off the top of my head. is to have the admins of lists.openstreetmap.org create a mailing list for your local group, along the lines of talk-us-newyork (but perhaps even more local). On Tue, Jul 19, 2016 at 6:37 PM, Jonathan Schleuss wrote: > Hi all, > > Is there a way to email multiple users at once? Prior to each local event > I copy/paste a markdown file into openstreetmap.org over and over again > to contact local mappers. It would save me so much time to email them all > at once. Is there anyway to do that? Or does anyone have tips for > other local organizers? > > Thanks, > Jon Schleuss > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Way to message a bunch of users at once?
Hi all, Is there a way to email multiple users at once? Prior to each local event I copy/paste a markdown file into openstreetmap.org over and over again to contact local mappers. It would save me so much time to email them all at once. Is there anyway to do that? Or does anyone have tips for other local organizers? Thanks, Jon Schleuss___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Status and progress: NYS DEC Lands reimport
Kevin: I am impressed with your very careful level of attention to detail here. While I personally can't help, I wish you the best in your endeavors to complete this import. (Perhaps the imports-us-request list might have been / could be a better posting place?) Thank you for your excellent update, rich and thorough in its presentation. Regarding your #5, well, I've been known to do this on occasion, too. As you say, it isn't "exactly a lie" so I'm OK with it. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Status and progress: NYS DEC Lands reimport
I just thought I'd make a quick follow-up here about the Long Island pine barrens. I'm rather being a perfectionist. A typical problem area can be seen at http://www.openstreetmap.org/#map=17/40.89045/-72.62721 . The original imported data simply had an approximate property line, and this line corresponds to the green-shaded region. A later mapper tagged this region with 'natural=wood', and added additional 'natural=wood' polygons coterminous with it. The reimport saw the 'natural=wood' tagging as something that had to be preserved, so kept the polygons while removing the tagging for landuse=* and leisure=*. It then overlaid the imported area, tagged 'leisure=nature_reserve' and 'landuse=forest' as well as 'boundary=protected_area'. http://www.openstreetmap.org/relation/6371616#map=17/40.89109/-72.62763 highlights the reimport. A later mapping also glued a powerline to the preserve's southern boundary. That took some manual repair. This means that all along the border of the preserve, there are bits tagged 'natural=wood' that are not in the preserve's boundary, and other bits that are in the protected area but not tagged as woodland. There's nothing fundamentally wrong with this - trees are no respecters of property lines - but it looks untidy, particularly since the original tagging was done based on the (incorrect) preserve boundaries. (Much of the included area, too, is not woodland, but scrub, or wetland, or brownfield.) If I don't hear from a Long Island mapper, I think continuing the process the way it began, with untidiness at the margins, is the best that I'm going to be able to do. It's at least not undoing the work of local mappers; with the exception that the protected areas are redrawn, every bit of land is left tagged as I found it. It may or may not be respecting their intent. Given that so much 'natural=wood' in that area is tagging areas that aerial photographs make clear are NOT woodland, it's hard to determine what was actually meant, beyond 'please paint this green on the map.' On Mon, Jul 18, 2016 at 7:31 PM, Kevin Kenny wrote: > The reimport of NYS DEC Lands that I proposed this spring is now complete, > except as noted below. Now would be a good time to check that I got it > right. > > I am aware of the following issues that need to be resolved before I call > the import 'complete.' > > (1) I have not imported a fair number of parcels in the Long Island pine > barrens. The reason is that local mappers have in many cases reused the > nodes marking the parcel boundaries as edges of polygons that specify > further land uses, or land covers (wood, scrub, wetland, meadow, etc.) In > many cases, these appear to have been attempts to tag for the renderer, > since inspection of aerial photographs shows land cover inconsistent with > the tagging (natural=wood on what is obviously a brownfield site or a tidal > flat, for example). This will require rather a lot of hand work to > reconcile, and it's in an area where I don't have recent "boots on the > ground" experience. If some local mappers from Suffolk County are willing to > step forward and help me, that would be a tremendous relief. I can put up a > .osm file with the DEC data as it should appear; other tagging (such as > natural=*, landuse=*, related tags) obviously has to be reconciled with > what's already there. > > (2) All the Long Island parcels, with the exception of the Ridge > Conservation Area, need a mechanical edit to replace 'access=yes' with > 'access=permit permit:website=http://www.dec.ny.gov/outdoor/7815.html.' I > was unaware of this restriction when I started the import, and put Long > Island on hold when I learnt about it, but there are a fair number of > parcels already imported that need to be revised. I can come up with a > script to identify them. > > (3) There are areas that comprise multiple separated parcels where a glitch > in the import resulted in duplication of the multipolygon relation. Northern > Montezuma Wildlife Management Area is the only one that I'm aware of, but > I'm working up a script to audit the entire import and report duplicates. > > (4) Wildlife Management Areas exist that are not the current incarnation of > the former State Game Farms. It would be a good idea to tag all Wildlife > Management Areas with 'protection_object=habitat' rather than the current > 'protection_object=hunting;fishing'. I fixed a couple of these manually, but > want to do a mechanical edit to replace the rest. > > (5) I want to add leisure=nature_reserve to the landuse=aquaculture and > boundary=protected_area that is present on the state fish hatcheries. This > is not exactly a lie, since the land is protected, and if it is no longer > used as a hatchery, it would revert to the default of 'state forest.' It's > consciously tagging for the renderer, since there's otherwise nothing there > that renders at all. > > (6) A number of parcels on the Hudson enjoy Federal as well as State > protection, as the Hudson
Re: [Talk-us] [Imports] Status and progress: NYS DEC Lands reimport
On Tue, Jul 19, 2016 at 8:25 AM, Greg Troxel wrote: > Martin Koppenhoefer writes: >> On this particular issue I believe you should use different tagging. >> Currently there is almost no use of access=permit >> http://taginfo.openstreetmap.org/tags/access=permit >> Typically if you require a permission for access it is "private" (maybe >> something with "access:conditional" would also be appropriate: >> http://taginfo.openstreetmap.org/keys/access%3Aconditional#values ), you >> could still link the detailed specifiication with a similar tag, like >> access:website=http://www.dec.ny.gov/outdoor/7815.html >> (choosing from the most frequently used tags, maybe it could be >> "source:access"?) > > It seems like the tagging schema should be improved. As I see it > there's a big difference between > > private, and really there is no expectation that some random person > can easily/reasonably get permission or that it's reasonable to ask > > a permit system, where it's controlled somehow, but really you can go > there after you follow the rules, and there's an expectation that > permits will be issued to those who ask > > The second case also sort of applies to backcountry in national parks, > except technically you only need a permit for camping overnight. > > > Perhaps you are saying that access=conditional has some established > semantics that would capture this. That was exactly my thought. The distinction is real, it's observable in the field, and it's common in places that I visit. New York has its permit system in place mostly so that the infrastructure will be there if they have to impose access quotas someday. For the Long Island pine barrens and the New York City watershed lands, the permit can be obtained immediately, free of charge, by entering your contact information on a web site and then printing the access card and parking tag. The access cards are good for several years, so you don't even need to do this for every trip. For the High Peaks Wilderness, it's even easier. They have permit tags on carbon paper forms at the trailheads. You fill out the form, take one copy with you and leave the other copy in the box. I left that one 'access=yes', since a traveller doesn't need to plan in advance for it. Moreover, I didn't have a good map of the zones of the High Peaks Wilderness, and the permit system applies only in the eastern zone. The boundary is indefinite, following the relatively inaccessible ridge over Nye, Street, and MacNaughton Mountains. In the unlikely event that I were to climb one of those from the west (a much harder route), I'd probably grab a permit card at Heart Lake or Keene Valley the day before. It would not surprise me at all to learn that this 'self-issued' permit system is a peculiarly American thing. It seems to be just the sort of messy and free-wheeling system that Americans are fond of, but doesn't quite fit OSM's model of the world. (OSM hass come around quite nicely, but I can certainly recall a time when the European cultural assumptions were fairly pervasive.) I had investigated access:conditional, but the schema doesn't seem appropriate. It appears to have a formal syntax that is devoted to specifying restrictions for the use of a motor vehicle router. I see that I could write access=private access:conditional="yes @ permit_holder" but that's even rarer than 'access=permit' - taginfo shows only nine uses of 'permit_holder' within 'access:conditional' in the whole of OSM, I'm already rendering a map using 'access=permit'. I can easily change the rendering to whatever tagging scheme is decided on. Nevertheless, it's important to my application, so there has to be some sort of distinction between 'private: keep out' and 'make sure you have your access card in your backpack'. Incidentally, this argument is one that I hate to use, because the last couple of times I mentioned that I can't tag two things exactly alike and expect to render them differently, I was accuesd of 'tagging for the renderer.' I think that argument rather misses the point: things tagged alike cannot be rendered differently, whatever renderer is in use. I do wish that the discussion had happened before I imported the New York City DEP watershed lands. At the time, I asked, on 'talk-us' and 'imports', how to deal with the situation, and someone suggested that the little-used 'access=permit' might be appropriate. As it stands, I now likely have another project to deal with revising that tagging, at such time as we arrive at a consensus what the tagging should be. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Updates:LA County building import (Los Angeles, California, USA)
Hi everyone, Another round of updates on LABuildings import. Last week we've imported ~1.1M buildings in LA City. Over 100 usernames participated. We are close to finishing Phase 1 (LA City) and will continue data QA and cleanup if needed. We've posted OSM diaries on the process: - On tools we built: https://www.openstreetmap.org/user/manings/diary/38969 - On the data: https://www.openstreetmap.org/user/manings/diary/39081 As always comments, from the community is appreciated. - Github - https://github.com/osmlab/labuildings/issues/ - Chat - https://gitter.im/osmlab/labuildings - Wiki - https://wiki.openstreetmap.org/wiki/Los_angeles,_California/Buildings_Import On Thu, May 5, 2016 at 8:07 PM, maning sambale wrote: > Hi, > > Over the past month, since we started the LA building import [0], > ~330K buildings were added by 74 different users [1]. We ran several > mapathon events [2] in LA to kickstart the import with local mappers. > > As this has been going on we've been validating the work, and fixing > any data quality issues we've encountered. If you have specific concerns, > please post in the repo [3]. > > The OSM Operations group has asked that we pause on all large mapping > import activities for the next two weeks as they prepare for the > upcoming > server move. Since we are adding thousands of nodes for each changeset, > this is slowing down the backup process. > > We will update the list once we get the green light again. [4] > > [0] > https://wiki.openstreetmap.org/wiki/Los_angeles,_California/Buildings_Import > [1] https://taginfo.openstreetmap.org/keys/lacounty:ain#overview > [2] http://www.meetup.com/MaptimeLA/ > [3] https://github.com/osmlab/labuildings/issues > [4] https://github.com/osmlab/labuildings/issues/88 > > On Mon, Apr 11, 2016 at 8:48 PM, maning sambale > wrote: >> Hi, >> >> We've started the import this during MaptimeLA [0] last April 2. >> First project focused on Southside LA [1]. >> For any issues regarding the process and the data please post a ticket >> in GH [2]. >> >> [0] http://www.meetup.com/MaptimeLA/events/229861154/ >> [1] http://labuildingsimport.com/project/2 >> [2] https://github.com/osmlab/labuildings/issues >> >> >> On Sun, Mar 27, 2016 at 12:20 AM, Christoph Hormann >> wrote: >>> On Thursday 24 March 2016, maning sambale wrote: > - Tagging still looks vague. What you have on > https://github.com/osmlab/labuildings/blob/master/README.md is just > a list of OSM keys to use but there is no information on the values > - Right, I updated the wiki to describe the tags. Still a work in progress, but see here: https://wiki.openstreetmap.org/wiki/Los_angeles,_California/Buildings _Import#Data_Preparation >>> >>> Thanks, this clarifies things a lot and mostly looks good. >>> >>> Regarding tagging plans please consider that building=farm is >>> exclusively for residential building on a farm, not for other buildings >>> with farming related use. >>> The initial offset we saw was due to re-projection issues from NAD83 to WGS84 datum. By using a custom projection parameters the difference is very minimal difference (10 micrometer precision range). Reprojection is now step is now added in the wiki. >>> >>> OK. I was also concerned about vertical datum (i.e. reference geoid) for >>> elevation values and feet vs. meters for ele and height. >>> >>> -- >>> Christoph Hormann >>> http://www.imagico.de/ >> >> >> >> -- >> cheers, >> maning >> -- >> "Freedom is still the most radical idea of all" -N.Branden >> https://epsg4253.wordpress.com/ >> http://twitter.com/maningsambale >> -- > > > > -- > cheers, > maning > -- > "Freedom is still the most radical idea of all" -N.Branden > https://epsg4253.wordpress.com/ > http://twitter.com/maningsambale > -- -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden https://epsg4253.wordpress.com/ http://twitter.com/maningsambale -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Status and progress: NYS DEC Lands reimport
Martin Koppenhoefer writes: > On this particular issue I believe you should use different tagging. > Currently there is almost no use of access=permit > http://taginfo.openstreetmap.org/tags/access=permit > Typically if you require a permission for access it is "private" (maybe > something with "access:conditional" would also be appropriate: > http://taginfo.openstreetmap.org/keys/access%3Aconditional#values ), you > could still link the detailed specifiication with a similar tag, like > access:website=http://www.dec.ny.gov/outdoor/7815.html > (choosing from the most frequently used tags, maybe it could be > "source:access"?) It seems like the tagging schema should be improved. As I see it there's a big difference between private, and really there is no expectation that some random person can easily/reasonably get permission or that it's reasonable to ask a permit system, where it's controlled somehow, but really you can go there after you follow the rules, and there's an expectation that permits will be issued to those who ask The second case also sort of applies to backcountry in national parks, except technically you only need a permit for camping overnight. Perhaps you are saying that access=conditional has some established semantics that would capture this. signature.asc Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
