no need for scripts, qgis does this fine via the Vector menu -> Geometry tools -> Simplify Geometries utility. I simplified it to 20cm with the , but I think 40cm is too aggressive.
I already have scripts to compile it into the dataformat needed to be served. On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel <bike...@gmail.com wrote: > Hi all, > > The wiki page is indeed looking a whole lot better right now - my thanks > and congrats to everyone who contributed! There is a still a ways to go, > but we seem to be getting there quickly. > > I'll echo John in saying that I would appreciate hearing from some of the > other people who chimed in to express their doubts about the import. For my > part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm thrilled that > we're talking and working together in the open, and that addresses the > biggest concern I had with the import. > > These are the big issues I see remaining: > > 1. *Validation*: Ideally I'd like to see a good chunk (more than half) of > the data that has been imported already validated by another user before we > proceed with importing more data. Validation is part of the import plan, so > the import isn't done until validation is done anyway. My hope is that this > will flag any issues that we can fix before moving forward, and give people > time to chime in on the import plan who maybe haven't already. I don't want > to see everything imported and only then do we start systematically > checking the quality of our work, if ever. If no one wants to do it now, no > one is going to want to do it later either, and that doesn't bode well. > > 2. *Simplification*: James' analysis showed that simplification could > save several hundred megabytes (and probably more) in Ontario alone. This > is totally worth doing, but we have to document the process and be very > careful not to lose valuable data. I believe there was also a concern > raised about orthogonal buildings being not quite orthogonal - this is > something that we should handle at the same time, again, very carefully. We > certainly don't want to coerce every building into right angles. With > respect to James, I'm not sure this is something that can be done with a > few clicks in QGIS. I would be willing to develop a script to handle this, > but it would take me about a week or two to find the time to do this > properly. We would need to simultaneously A) simplify straight lines B) > orthogonalize where possible and C) preserve topology between connected > buildings. This is not impossible, it just takes time and care to do > correctly. > > 3. *Speed and Size*: To John's point, it seems like people certainly are > not sticking to the areas they know, unless they get around a whole hell of > a lot more than I do, and yes this is a problem. The whole Toronto region > was basically imported by two people: DannyMcD seems to have done the > entire west side of the region (hundreds of square kilometers) while > zzptichka imported the entire east side of the region (again a truly > massive area), both in the matter of a week or two. They only stopped in > the middle where there were more buildings already and things got a bit > more difficult. The middle is where I live, and when I saw that wave of > buildings coming, I sounded the alarms. > This is way too fast - no one person should be able to import the GTA in a > couple weeks. A big part of the problem, IMO is that the task squares are > much too large, and allow/require a user to import huge areas at once. At > the least, some of the task squares in central Toronto are impossibly > large, including hundreds or thousands of buildings already mapped in OSM. > Conflation on these, if done properly would take the better part of a day, > and people are likely to get sloppy. > I would like to see the task squares dramatically reduced in size as a way > of slowing people down, helping them stick to areas they know well, and > keeping them focused on data quality over quantity. This would also make > the process much more accessible to local mappers who don't already have > tons of experience importing. > > 4. *Conflation*: I don't think the current conflation plan is adequate(ly > documented). In practice, what people are actually doing may be fine, but I > really want to see some better thought on how to handle existing buildings. > Right now the wiki says for example "*Before merging buildings data > switch to OSM layer and see if there are any clusters of buildings without > any meaningful tags you can delete to save time when merging*." > With respect to whoever wrote this, this approach seems to value time over > data integrity and I just don't think that's how OSM should operate. We > need to be more careful with the existing data, and we need to show that > care with clear and acceptable guidelines for handling the data that > countless people have already spent their time contributing. We don't do > OSM any favours by carelessly deleting and replacing data. Help convince me > that this isn't what's happening. > > Until some effort has been made to address these concerns, I will continue > to oppose this import moving forward. And to be clear, I don't want to > oppose this import - I have too much else I should be focusing on. I just > don't want to see another shoddy import in Toronto (or elsewhere). > > Best, > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > On 1/26/19 8:49 AM, john whelan wrote: > > I'm not certain how this addresses the concerns raised by Andrew Lester > and > > Pierre Béland, and I seem to recall one other person who expressed > concerns. > > I think it is important that their concerns are addressed. > > Perhaps they would be kind enough to comment on whether or not this > approach addresses their concerns. > > Do we have a concern that some mappers have been importing buildings > further than say twenty kilometers from where they live? > > > Have you found volunteers of local mappers in > Alberta > British Columbia > Manitoba > New Brunswick > Newfoundland and Labrador > Northwest Territories > Nova Scotia > Nunavut > Ontario > Prince Edward Island > Quebec > Saskatchewan > Yukon > > Who will be willing to oversee the import in each province? > > Does this mean the smaller provinces may not see any data? > > How will you handle cities of say 80,000 population in a smaller province > who have an interest in seeing their buildings available but have no idea > on how to contact the provincial group? > > > > If we go back to earlier times it was a suggestion in talk-ca that we use > the single import approach and it was mentioned at the time there didn't > seem to be a list of local mapper groups in Canada. > > I'm not saying the approach of a single import as far as the import list > and talk-ca followed by a procedure of locally organised mappers bringing > in the data is wrong I'm just trying to ensure the project moves forward > and we are in agreement. > > Thanks > > Cheerio John > > On Sat, 26 Jan 2019 at 00:17, OSM Volunteer stevea < > stevea...@softworkers.com> wrote: > >> Thanks to some good old-fashioned OSM collaboration, both the >> https://wiki.osm.org/wiki/Canada_Building_Import and >> https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020#NEWS.2C_January_2019 >> have been updated. (The latter points to the former). >> >> In short, it says there are now step-by-steps to begin an import for a >> particular province, and that as the steps get fine-tuned (they look good, >> but might get minor improvements), building a community of at least one or >> two mappers in each of the provinces with data available, the Tasking >> Manager can and will lift the "On Hold" or "Stopped" status. >> >> Nice going, Canada! >> >> See you later, >> >> SteveA >> California >> _______________________________________________ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ca >> > > _______________________________________________ > Talk-ca mailing > listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca > > _______________________________________________ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
