Re: [Talk-ca] Telenav mapping turn restrictions
Hi Martijn, Am 26.04.2017 um 18:22 schrieb Stewart C. Russell: > I know that Github issues are the industry standard, and the OSM > comment/discussion mechanisms may seem a little quaint, but we risk > talking past one another if we splinter the discussion. Just my 2 cent as a non-Canadian. I think you, Martijn, cannot expect an average mapper to sign up for Github (a platform which belongs neither to the OSMF nor to any local chapter) just to be able to complain about someone else edits. There is already a plenty of platforms which can be used to discuss things in the OSM universe, changeset discussion and this mailing list are two of them. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] Ottawa Buildings & Addresses [Statistics Canada project]
Hi James, Am 2017-01-24 um 21:05 schrieb James: > The sources are now available on the city of Ottawa's website. As such was > the major hurdle last time to proceed with the import and it is now taken > care of (http://data.ottawa.ca/dataset/urban-buildings) and the local > community in agreement to proceed, we shall begin to do so in the coming > days. Thank you for the link to the data. The link to the license on that page (http://ottawa.ca/en/mobile-apps-and-open-data/open-data-licence-version-20) returns error 404. archive.org has an archieved version of that page from October 2016 but it would be better if their open data portal contained working links to the license texts. You are in touch with them, aren't you? Could you please ask them to fix that broken link. Please note that this is not a show-stopper. > The documentation has been updated here: > https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan > Please refer to it if you have any questions. The license (http://ottawa.ca/en/city-hall/get-know-your-city/open-data) linked from the wiki page contains the phrase "for any lawful purpose". Is it compatible to OSM? I don't know if it is compatible, I haven't looked if this issue has been solved or is still open. There was some discussion about licenses with such phrases on Legal-talk mailing list some months ago. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Light rail mapping questions
Hi Mike, Am 2016-10-22 um 20:43 schrieb Mike Boos: > I don't know if I'd characterize this as a "Karlsuhe model" train-tram - > the system is entirely within a single urban area (even if it does span two > adjacent cities), it just uses an existing rail corridor in some places. > Unlike the Karlsuhe system, the vehicles have only a single operating > voltage. There are lines in Karlsruhe which use only the tram current (750 Volt DC), e.g. line S1 from Hochstetten via Karlsruhe to Bad Herrenalb. This line shares tracks with freight trains between Lepoldshafen Frankfurter Straße and Welschneureuter Straße. That's similar to the train track in Waterloo. >> Tag the tracks as they look like. Sections where tracks share space with >> cars [1] are railway=tram. Where the trams are physically separated from >> the traffic [2], it's a railway=light_rail. That's how tagging works in >> cities which only have *one* tram/light rail system. If the city has two >> or three (low-floor tram and high-floor light rail; some German cities), >> it becomes more difficult because we also try to get the systems >> distinguishable (there are use cases). But that is not important now and >> the reason why Germans discuss correct tagging of trams, light rails and >> subways at their OSM Forum over multiple pages and threads. :-) >> > > There are not really spaces shared with cars, (thank goodness) so the only > appropriate tag along roads is light_rail. It does not share the space but according to your photos at Twitter the trackbed seems to be paved and cars could use it. A proper light rail has either ballast or grass between the tracks, i.e. car drivers will recognize that the cannot use this space. https://www.mapillary.com/map/im/jx4Z1BdL_nhENDjJMxHI2w http://www.regum.de/en/rail_products/lawn_track There is no sharp border between trams and light rails. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Light rail mapping questions
Hi Am 2016-10-22 um 21:11 schrieb James: > Could lanes work? > https://wiki.openstreetmap.org/wiki/Lanes > > Example: > https://wiki.openstreetmap.org/wiki/Lanes#Two_driving_directions > > What ever the train tag would be: > train:lanes:forward=no|yes > train:lanes:backwards=no|yes > Then for passenger cars would be opposite? > car:lanes:forward=yes|no > car:lanes:backwards=yes|no > > I'm not sure about this maybe Micheal has more insight on this I would use different tags but the ideas is similar. The right/back of the photo: lanes = 4 lanes:forward = 2 lanes:backward = 2 access:lanes:forward=no|yes access:lanes:backward=no|yes tram:lanes:forward = yes|no tram:lanes:backward = yes|no The left of the photo: lanes = 4 lanes:forward = 2 lanes:backward = 1 turn:lanes:forward= tram:lanes:backward = no|yes access:lanes:backward = yes |no Differences to James' suggestion: My suggestion is compatible with the widely used lanes tagging scheme. I used "backward", not "backwards" (see Taginfo). I used "tram", not "train". Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] City of Ottawa imported buildings & addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Denis, hi Rps333, hi LogicalViolinist [3] Am 19.10.2016 um 08:31 schrieb Denis Carriere: > Ok this Ottawa reverting process is getting out of hand now! > Frederik (woodpeck_repair) is reverting entire user history without > looking at what his osm-revert-script is doing. > > *Before & After of Revert - More info with photos* > https://gist.github.com/DenisCarriere/581b3dbc6adf36608f470702d0bcc38d > > This all started because a "building:level" tag was removed by > accident in Stittsville, it happens, don't cry over it. > > As for "lack of discussion" we've been planning this for months and > invited all the local mappers to events & we've also got the > license agreement from the City of Ottawa. > > So why are you reverting possibly hundreds of hours of work done by > the local OSM Ottawa group? > > If you're only concern is documentation and workflows, then we can > easily provide it, no need for an emergency revert of entire users > histories (LogicalViolinist, Rps333, DenisCarriere) all of them are > very active contributors. I have the impression that we are talking to a brick wall. As people have pointed out on this mailing list for the last days, your import lacks nearly everything which is required by the guideline. Please read the postings of the other people on this mailing list carefully. Additionally, I hereby ask you, DenisCarriere, Rps333 and LogicalViolinist not to upload any buildings or addresses, modifying or deleting them before the full revert is completed. Don't try to start or continue any edit wars [1,2]! Don't restart the import just after the revert has been finished. Do everything which is required by the guideline. [4] I hope we do not need a fifth user block within three days to enforce these rules. :-( Best regards Michael [1] http://www.openstreetmap.org/changeset/42988442 [2] https://www.openstreetmap.org/user_blocks/1067 [3] email address unknown [4] You have to wait about two to three weeks between asking on a mailing list for approval and starting the import. - -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYBxsuAAoJEB87G9rMCMyIencP/1AJeB422kfwhNxOF8AQiCqb 0PGs6tYQ1WKReuc+EW03NoDEje+MI7+zn7TRu/8XLxuRPDfF9Ip7nHRnR3x7IVrZ zD0ySfIZm6ynNOIvk1W/AVtyLZuKCvEjLIDaDZc+WSH9Hi4vqEe/k14NOM9TZlYh 8IijlE2iDP9sidmrKTedMpBnJk65BG6q/ZnazDHje2QH23Vamg7WSdiIxIQFcHBg Fs7sRpexBaZAQ7vV1x+Abfc4UvHmx1tZjWDweC1QB2TQIg5wRQp+q4RTXghXQix0 Mc4KS387W1NG56XAtnPJdO+Jmd3lCwJygdH7p4lOZlBBnI1WDzt9meBHLBmThNac gsSi+5+F0Jo6XqozlJafWm3dVoX/sP18tPUlqY6d3e6DQWjPDS0ToXIRrleOzIeH sQmvU5xWmGdn6A+2XWAPW21CS2p5DrFt41asz26dShgs//PkJKR2OOEB2THQ/D5B yxaLNMDAmCaU65vxwpS1gYwKcDXrQnaKj+DV+YwivyCTG/84WfZOuFugJcEc/HtR DyWxnnz0oZqAHswMYdveUhIFVorRSpjoB4cMVM/0SllwVPiwA6vrZ4rbDnO7IzpJ lUIkvBJHuT8+b9j6j1HBPfCU6b00BwsgRJtxVP65RGbxcHuIpdPRv0RVko/QrCNG +FKuVzzZNMqvbHYhGrMR =PyeV -END PGP SIGNATURE- ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Light rail mapping questions
Hi Mike,
Am 18.10.2016 um 03:52 schrieb Mike Boos:
> Along on-road sections, the dedicated rail right-of-way moves from
> centre-running to the outsides of the street at certain intersections. (A
> by-product of some of the political compromises in route choices.) Does
> anyone know of any examples of tracks going from the centre to the side of
> the road with traffic lanes in OSM? I expect these are going to look messy.
Look at any German, Austrian or Swiss city of your choice where every
tram track is mapped as a single way in OSM (i.e. no tracks=2). I need
more details (show us photos) to give a useful answer.
> There are also portions of the line that will share track with a freight
> corridor. From what I can tell, convention appears to be to tag it with the
> heavier mode, i.e. railway=rail instead of railway=light_rail. However, the
> use of the track for freight is quite small - at most one freight train
> to/from Elmira uses the track at night, when light rail service won't be
> operating. Should the track still be marked as 'rail' instead of
> 'light_rail,' or should we attempt to have the tags represent the dominant
> use? (At present, some of these are tagged as railway=construction, even
> though the freight train has been consistently using it overnight. This
> section is also largely complete.)
Yes. If the track is still usable for freight trains (even if limited to
certain hours), it is a normal railway track and therefore gets
railway=rail. What you describe is called "Karlsuhe model" – don't
confuse it with our tagging scheme at OSM. ;-)
I assume, that some people of Grand River Transit have visited the
German cities Karlsruhe and/or Kassel. :-) The first one has been
operating a tram-train system for more than 40 years.
https://en.wikipedia.org/wiki/Karlsruhe_Stadtbahn
https://en.wikipedia.org/wiki/Kassel_RegioTram
Tag the tracks as they look like. Sections where tracks share space with
cars [1] are railway=tram. Where the trams are physically separated from
the traffic [2], it's a railway=light_rail. That's how tagging works in
cities which only have *one* tram/light rail system. If the city has two
or three (low-floor tram and high-floor light rail; some German cities),
it becomes more difficult because we also try to get the systems
distinguishable (there are use cases). But that is not important now and
the reason why Germans discuss correct tagging of trams, light rails and
subways at their OSM Forum over multiple pages and threads. :-)
> Further, there is gauntlet track to allow freight trains to pass station
> platforms. Do we tag the track closest to the platform as
> railway=light_rail and the outer track as railway=rail? There's some
> discussion here on gauntlet tracks here that suggests this is the case in
> Europe: http://forum.openstreetmap.org/viewtopic.php?id=29131
It is the case in Kaufungen near the city of Kassel which has a
Karlsruhe-like tram-train system ("Regiotram").
https://commons.wikimedia.org/wiki/File:Haltestelle_Niederkaufungen_Mitte_02.JPG
Yes, the track for heavy trains is a normal train track (railway=rail)
while the outer ones can only be used by light rail vehicles due to the
smaller structure gauge. Therefore the light rail track gets
railway=light_rail. Because we map one way per track at the centerline
of the track, there are two (in Kaufungen three) parallel tracks and all
get railway:interlaced=yes. This is useful for routing engines.
If there were up to date Mapillary photos, I could give more and better
advice. (Mapillary photos by pedestrians are better because are located
on the sidewalk)
Greetings from Karlsruhe
Michael
[1]
https://www.mapillary.com/app/?focus=photo=EztyFQ4j2CHqglj_C-Uilg=48.99870833326=8.3937401=17
[2]
https://www.mapillary.com/app/?focus=photo=gejtgJYKdJrqZ_8M0zcDFQ=50.935379=6.957689=17
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
signature.asc
Description: OpenPGP digital signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] City of Ottawa imported buildings & addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Denis, Am 17.10.2016 um 23:22 schrieb Denis Carriere: > *(Frederik Ramm) *just did a mass revert [0] with his revert script > [1] created in 2009 and now we have 20,000+ warnings of empty nodes > within a small section of Ottawa [2]. > > Not only did *(Frederik Ramm) *undo James commits, but now you've > introduced over 100,000+ warnings scattered across Ottawa which is > near impossible to fix unless we revert the revert. > > If you're going to undo someone's commits, at least do it right and > not corrupt the OSM data for the Ottawa community. > > Please remove all of the empty nodes you've just created from your > poor revert, have you even looked at what you reverted?? The revert has not been finished yet (the changeset is still open) and its necessary first to delete all created relations, then all created ways and, as a last step, all created nodes. It is a usual effect that reverting huge bulk uploads takes hours. Best regards Michael - -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJYBUQrAAoJEB87G9rMCMyICaQP/Rb1r7QNXL2lDjWHCzePQyCG Ega6AmJN1CPjsWSTWy9H7CQrJ605n1UA3E9vDOCSXyeGkNuQ9XzyQgqcrgbGPqda H2evRlLMwg8x6GA+UcgALSSaD1ohJwzARCzrnXactt0Y/o5t6uPkLkvUzw8/JWNZ nvtLtiLHeksY5SAlZPiuUFp0d5yR6MPRjD53TOTuGpNBcwttSIG30tbP/rOkjysw W/2bOLLXDFd/VTtel3jrfuBiPS+ZbRYYKik5hgeZyMjCVeMKRyr4mOHTigddC0Tw TtTfNkL1riRE/8jWE75p7WTiYayTgDshX7VidHMVeI1pt5JSgFiePAQYHBcKRKM2 /DlDkLTfH+6xB46Yq8mTSMPr55vOJ1qB1X4IvVFjgAHA/9CDxnswhko0qdXayt9a mZ5mnXA/rKbnocnunzv1F7rsMuWa2m9NKo/14equs4buCW8wWk8XJ4Kgj400dWNi SLNYiyD9/XiMzHXJO7Atb5cuvOM8+bt/C0Xz+FHTn4aEsYDqYNHcH0bzrCgsxV/D EAoyoFQUR7eh9Fr1fCnweH0BGgKqxQGlEIr8YHC+I9jXzTiy1/QftpLLsIVgaoZ4 HdeWUa89MFD2rbYtEDO5WMDWEbNwuW2IzEimvkaYd7XFhYwaE0MY02EeeRlQPBYi iXvuH9bdFT7p3rWba4xr =6HD7 -END PGP SIGNATURE- ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] City of Ottawa imported buildings & addresses
Hi, Am 17.10.2016 um 19:20 schrieb Michael Reichert: > I have asked a DWG member to block him to stop the ongoing import and > start a discussion. > https://www.openstreetmap.org/user_blocks/1065 The second user block (now for three hours): https://www.openstreetmap.org/user_blocks/1066 reason: https://www.openstreetmap.org/changeset/42965430 and similar changesets Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] City of Ottawa imported buildings & addresses
Hi James, Am 17.10.2016 um 19:37 schrieb James: > Like this one Kevin? > https://lists.openstreetmap.org/pipermail/talk-ca/2016-July/007034.html > > or this one? > https://www.mail-archive.com/talk-ca@openstreetmap.org/msg07024.html > > or this one? > https://lists.openstreetmap.org/pipermail/talk-ca/2016-August/007151.html > > or this one? > https://lists.openstreetmap.org/pipermail/talk-ca/2016-August/007068.html > > Tired of googling, but it's the ones I found in a couple of seconds I have been subscribed to this mailing list for about two months and saw that there was a discussion on this mailing list but I cannot find a discussion on *Imports* mailing list. https://wiki.openstreetmap.org/wiki/Import/Guidelines#Discuss_your_proposed_import says > Discuss your import on the impo...@openstreetmap.org mailing list and > with appropriate local communities. That's not the only reason why this import is bad. See my other posting for all the other reasons. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] City of Ottawa imported buildings & addresses
Hi AJ,
Am 17.10.2016 um 18:59 schrieb AJ Ashton:
> I haven't seen any substantial discussion about the Ottawa buildings &
> addresses import anywhere. I did see the thread a number of weeks back,
> "Crowdsourcing buildings with Statistics Canada," but I didn't see
> anything discussed that sounds like the planning of a mass import. The
> wiki page linked from the discussion [0] is completely empty. From a
> changeset discussion I was pointed to another section of the wiki [2]
> which again has few details and does not sound like an import
> ("...inviting contributors to crowdsource information on buildings").
>
> [1]: http://wiki.openstreetmap.org/wiki/Ottawa_Gatineau_Buildings
> [2]:
> http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Crowdsourcing_buildings_with_Statistics_Canada
Thank you for highlighting it.
In addition to the lacking documentation, LogicalViolinist neither uses
a dedicated account nor the import has been discussed at the Imports
mailing list (I had a look at the subjects of the last six months). He
has been informed about the Import Guideline on August 29, 2016.
https://www.openstreetmap.org/changeset/41776742
I have asked a DWG member to block him to stop the ongoing import and
start a discussion.
https://www.openstreetmap.org/user_blocks/1065
Best regards
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
signature.asc
Description: OpenPGP digital signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Import] Local community approval building & addresses in Peel region
Hi James, Am 08.09.2016 um 18:49 schrieb James: > As per the import guide lines I wish to seek approval for importing > building outlines and addresses in the region of Peel. > > Documentation is available here: > https://github.com/osmottawa/imports/blob/master/Peel-Region.md You know that the import documentation has to be placed at OSM Wiki, didn't you? Step 4.2 of import guidelines says: > You must write a plan for your import in the OSM wiki. Create a wiki > page outlining the details of your plan. […] Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Reverts
Hi Sam, Am 01.09.2016 um 23:06 schrieb Sam Dyck: > I received the following changeset comment from Nakaner for a Canvec import > (changeset > 38158126) at 15:55 Central Time (20:55 UTC): > > "This changeset has uploaded data which does not fit to each other. There > is an offset between the water areas and the forest areas. Example: > https://www.openstreetmap.org/way/406539219 > > Could you please fix this?" > > I believe the given what we have just spent the last 24 hours discussing > this request is unreasonable and the issue is not significant. Thoughts? If you have a proper look at the whole area around, you will see that there is a systematic offset between the water "layer" and the forest layer. The forest layer should be moved about 10 to 30 metres to northwest. I wonder how such an error can be overseen during the preparation of this tile. Other examples: https://www.openstreetmap.org/way/402043390 https://www.openstreetmap.org/#map=16/49.3997/-87.4329 Maybe the original data was traced from different aerial imagery and that's why there is an offset which is not constant. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] broken forests in eastern Canada
Hi John, Am 2016-09-01 um 14:47 schrieb john whelan: > The Canvec data was imported with the knowledge and support of the local > mappers and I think that's all that matters. An import of such a size and has to be discussed and approved on an international level. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Reverts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Am 2016-09-01 um 13:22 schrieb john whelan: > In many parts of the country there are no local mappers for many > miles or kilometers if you prefer. We do have some very > experienced GIS people around and I'm under the impression that we > really do know what we are doing. This is no carte blanche to import any dataset you can get. The import discussion exists to ensure that an import is done the right way, i.e. importing good data in a good way. If the users who import a dataset base on an import disussion/proposal do not care about the quality, they violate the proposal and therefore the policy because the import becomes an import which has not been approved. Best regards Michael - -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXyCKEAAoJEB87G9rMCMyIqvgQAK58kt5ULsvv0nf0MnCm6ahM Iq8Kub3bLS2ZE93kVlgUl43cEJ6pzr3/XS0fd4hbRPuybektD0N9kNumm/KVZ2Pn 2/fZvOpai3YcVRAiSMZ2HUHaZnz9CYI56xsFYJcE8+RXcmTBXbp1WBmbqd4j7ceu +IRdkrxweAQEDymlYtfI1rd1gA+CJBWnfcRr7Fq1CUNi2yI4M4U697qxtK1TdQuW 4Y+SmiDlUvGJLos0qjzucXs3zatY5SELY3/sTZ4iS0Emla8m5Eq1Wqo09FCGngrT Yov1gQQBuMlUl80BsILM6beAKfhYq0hYgje77VzONmZYN79mMzkXHD3IJS2/lVfZ r4pU2BL6bDTYues0diPefNbCvTi0SkLAOJccsy4+6OLWQ5B9WJgW8yT3KTbv6N0T 25yuaEGBdbLcs4dacZj1PdMKy2W4EgTy2UQKadlc4l4DAVJYyuaLifx0ij8n5pgs hepMWWTh0B5WyIckDGVMBUk9awQFu1IN7gm5zJWgTap6Kz3m0O0TbvOGtaXjod7C teFq+MmZ7wf/ocGc0AMCweZgJUBKiTu+tcKYrFUQq4f6XSCblzYiSJA95NlRNGJh BiLVgu/K7nJ1fYgPhN9wSVGgP21HRs80X2ZVtGLbTL/hZTjSDKNLd8sS6tT+86Ie ek7VLR9LDoAeihcRu3zU =Ea1G -END PGP SIGNATURE- ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] broken forests in eastern Canada
Hi, Am 01.09.2016 um 01:21 schrieb dega: > On Aug 31, Daniel Bégin wrote: >> On the same topic, it has been suggested to split wooded areas in smaller >> chunks by using features on the ground as outer limits (mostly roads, >> streams, rivers) and get rid of arbitrary rectangles from Canvec. >> Is it something we are aiming at? > > The grid is an important source of problems. Here are some examples: > 1) If a lake is on the grid, it will be split in 2 parts. Each part will have > a name tag and and 2 identical names will be displayed on the map, one on > each > part. This problem exist in thousands of lakes. I even saw a lake with a > triplicated name. > Merging the parts would require modifying 2 or more relations and many > importers don't do it (even if they use JOSM) because of the complexity. Some > have used a quick fix where they remove names from the parts and put it in a > POI. It looks fine but that's bad for database integrity. If someone does not merge two lakes because it is too "complex", he should evaluate if he is the right person to import such data. If an import contains much multipolygon relations, the people how import the data should know how they work, what can be done wrong, how to edit and how to fix them. :-/ > 2) A addr:interp way may be split in 2 parts. 2 consequences: > - the interpolation way become useless because it's now 2 different objects. > - the mid-point becomes 2 superposed nodes. Useless duplication. > > 3) A grid tile has a fixed size. It may be appropriate for unpopulated areas > but it is too large for urban areas where editors work at a high zoom level > (17 and up). It's easy to damage a relation without knowing it. > > But there are other problems (not related to the grid): > 4) the relations seem to be designed to be stand-alone. Thus the relation > borders don't share a way. They use 2 superposed ways. Useless duplication. > It's very confusing and we frequently alter the wrong way. > > 5) lakes are represented by 2 superposed identical objects, one for the hole > and one for the lake. If the hole happen to be on top, the name will not be > displayed. It's an unjustifiable complexity for the casual user. > I've also seen triplicated contour (one for the lake, on for the inner role > and one for the outer role) > > Yes, all these quirks can be fixed manually but it's time-consuming and error- > prone. What about reverting the tiles which have all these issues and seem to be uploaded with too few checks beforehand, run a better version of the preprocessor on the CanVec raw data and reimport them again? (That causes a loss of OSM history but an import changeset is not as much valueable than a manual changeset) > Ideally, the contour of a forest must not split any object and it's not > possible with a grid. > The sole advantage of a grid IMHO is to simplify the CanVec exports. What about replacing the grid by less artificial borders, e.g. roads, rivers, powerlines etc. If an area has too few of theses objects, artifical borders could be automatically drawn which are optimized to cut as few objects as possible into two parts. > Some years ago I would have proposed that someone write a guide "How to fix a > CanVec import". But now I would rather propose that someone write a "How to > pre-process a CanVec export before importing it into OSM". +1 All ongoing changesets which import CanVec data should either use an improved version of the preprocessor or should undergo the manual quality checks I described in my other emails and the changeset comments. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Reverts
Hi Daniel, Am 2016-09-01 um 12:26 schrieb Begin Daniel: > Furthermore, I hope you will not use you 100 objects per minute to decide > whether or not you will delete a changeset. I think this threshold is value > doesn't' apply (see below) > > Daniel > > About the100 objects threshold. > From my experience, if I load a Canvec tile in JOSM, make all the necessary > corrections and then import the result to OSM, I throw up to 25K objects to > the database within five minutes. As far as I know, the timestamps attached > to the changeset and to the objects is generated by the OSM database when > receiving the data. The five minutes it takes to upload the data to the > database (5K objects per minute) do not reflect the time I spent editing the > data prior to the upload. That's the base of my calculation I did with Rps333's changesets: changeset start end object count 3951757119:30:5319:32:564311 3951768619:35:3019:41:1211724 3951794419:45:1519:47:274963 3951814719:53:2520:04:5519286 As you see, he took less than three minutes minutes after uploading 39517571 to prepare 39517686. You cannot check such an amount of data very well within that time. Best regards Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) signature.asc Description: OpenPGP digital signature ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec Reverts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, unfortunately posting via Gmane does not seem to work (the website is down but NNTP still works), that's why I have to start a new thread. :-( Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck: > After reading through the changeset discussion, I discovered that > one of my imports in Northern Manitoba made Worst of OSM. > (http://worstofosm.tumblr.com/post/22180046353/dear- > openstreetmap-isnt-it-strange-how-the). As someone who spends a > some time amount of time in some of relatively unpopulated areas of > Canada and makes an effort to check the quality of Canvec data > (which is usually pretty good), I do agree that it is impossible to > do everything to the same level of quality that we would provide in > Toronto or Timmins or even small prairie towns. First of all, it is ok that an import takes a few years and therefore creates ugly green rectancles on the map. If an import is "unavoidable" :-), a manual import is the best thing that can be happen. But if someone uploads a changeset without a manual review beforehand, he counteracts the aim of a manual import: addind good data to OpenStreetMap. That's what I am mainly fighting against. If a users uploads much more than 100 objects per minute [1], you can be sure that he has not done any manual review. A manual review by myself confirmed this these. I am fighting against such changesets/users. A good imports must be reviewed *before* it is being uploaded. The review contains: - - Run JOSM validator, fix all warnings and errors. This includes all warnings regarding validity of areas. (you can argue if all warnings about "deprecated" tagging have to be fixed) - - Compare the data with available imagery. Is the forest really a forest or is another tag more appropiate? Right-click on a Bing tile at JOSM and have a look how old/recent the imagery is. - - Check if CanVec data fits to itself. http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt- it-strange-how-the - - Check if there has been any other data before. If yes, adapt the either the CanVec data or the old data. https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins ide-Cutting.png https://www.openstreetmap.org/way/439631732 - - Ways should not overlap with other ways if it is not necessary. The outer ring of a lake should also be inner member of the forest multipolygon. Maybe the program which created the OSM files should be imprved? - - Keep the history. https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history If a tile has been imported without being checked manually and no post-upload fixes have been done (i.e. upload without any checks), I will not shrink from reverting it. If a tile has been uploaded to OSM without a review and if it has not been fixed within a month, it is worthless and can easily be reimported at a later time if someone has the time to check and fix it. For the future, I will abstain from reverting changesets which have been imported before September 1, 2016 and whose users are currently doing the fixes that should already have been done. But if I come across an imported tile of low quality which has not been touched for a few weeks and is full of errors, it is just a question of time until it is reverte d. Best regards Michael [1] I had a look on a few of my changesets which added a large number of buildings to OSM. The fastest changeset contained about 60 objects per minute and was full of missing buildings as I later detected while collecting the housenumbers and usage of the buildings. - -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten ausgenommen) I prefer GPG encryption of emails. (does not apply on mailing lists) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXx77+AAoJEB87G9rMCMyI95YQAJyCMY/Qtnqu4C3MpLPrrwTH vN2aVBNoKHL+i6r5VBTPFy4JhcacjbAZSseMCbmQHo6CSdPgVk9Jvnk/Keh3ihH6 r//EqwqRnSPPE+JIBktW0DG50jzcogWun3UQmOyA/blRfYEZaIDhjRDjMcivBWvs x8EGZsuX/mraX74ucTbfhy13Xoy4M4Yjf4ibNS7ZmJKlT4Zj8HDwlPKRzFxZ6iWG JGfibU4wxxvJlQDWqjrVRN6zacbt8SKh9sHU3M88kNRhM+eido/rYY9LiKBFdO21 TBGM/XkvxcqM7F9u9uC03caDFi0cTb7PLZgv90QhXTi2DuFobfHf3sc1czq8lGeB Wa8ZZqRI6Y9/SV06P/wydA48caKeeO3OiiuH8UXzEZJPauUhLjpEVxY1OixkgNkC GR79KbVcx0AyFK66Jnrdn2pqa2HotJ2rM6RLSi68mMOYPbHcUvujcb7XQW5dvubF L3TamnVs8u1qiifpfTCAp/AJFxd/9UDnGi2VsjSHrIPdZgJaCAcHmhiUSXkcZa55 hjfL+4b+itj48PRcfJRzXTRE3I9Q7oAyMkbwMKVFvSOe9GwgUNw5nvspWvPUriUo pDoDHFJt3k4RE6hHVhsb0+L/OyVr6NFpjex2aoEbX0990Gvi+G6uabkNAOn4o0Ub nAQhtQWnI5dlwMWhcYOH =vPJv -END PGP SIGNATURE- ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
