Re: [OSM-talk] Article sur Geovelo dans l Usine Nouvelle
>> Bonjour, >> Un article sur Geovelo dans l Usine >> Nouvelle>>https://www.usinenouvelle.com/article/geovelo-l-appli-qui-federe-utilisateurs-et-collectivites-autour-de-la-pratique-du-deux-roues.N1034384 Hi, Sorry for that, wrong mailing list CheersJulien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Article sur Geovelo dans l Usine Nouvelle
Bonjour, Un article sur Geovelo dans l Usine Nouvellehttps://www.usinenouvelle.com/article/geovelo-l-appli-qui-federe-utilisateurs-et-collectivites-autour-de-la-pratique-du-deux-roues.N1034384 Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] expanded outdoor map on www.freemap.sk/?layers=X
Le jeudi 9 juillet 2020 à 21:41:06 UTC+2, Martin Ždila a écrit : Hello, > Let me announce that we have expanded our outdoor map to more (european) > countries. You can see it in action at www.freemap.sk/?layers=X > Most of it is the work of a single person (me) doing it in his free time and > therefore some features may not be 100% user friendly. Very nice ! Hope to see France covered one day, my holiday destination is not so far from the coverage limit :-( Cheers Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] an interesting read about Mapillary-Facebook
Le mercredi 1 juillet 2020 à 12:13:31 UTC+2, mbranco2 a écrit : > - "Why on Earth did Facebook Just Acquire Mapillary?", by Joe Morrison > [1]Linked in the previous article, another interesting paper:- "Corporate > Editors in the Evolving Landscape of OpenStreetMap" [2] > Very interestring, thanks! Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers
Le jeudi 12 mars 2020 à 15:43:17 UTC+1, Simon Poole a écrit : > To use a completely different example: assume that you purchase a TV set paid > by monthly instalments and you default on them. In civilised countries that > doesn't give the seller the right to break in to your apartment and repossess > the TV, they don't get to cut off electricity to the flat and they don't get > the right to stick big notices on your doors. The seller needs to utilize the > whatever tools are provided by the legal system, totally regardless off how > upset they are and how righteous they might feel about their actions. Hi Simon, My internet access provider provide IP TV. If I`m late to pay my TV display a message saying I cannot look at stream until my debt is payed and this is perfectly legal even it targets me precisely. My Internet access provider don't break into my appartment neither modify my TV, this is just the stream it sent to me. In the case that interest us this is the stream of tile that is modified in the same way except this is due to a non-respect of license instead of a debt. Best regards Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] ODBL, Trivial_Transformations and Specialised format databases
Hi all, I ask myself a question about specialised proprietary format database used in some applications like by example smartphone routing applications. Quite often these applications propose you to dowwnload some map files if you want to use them Offline. The issue I see with this is that user is dependant of the application provider for map update or scope cover by map extract. I looked at this page : http://wiki.openstreetmap.org/wiki/Open_Data_License/Trivial_Transformations_-_Guidelineand especially part called Specialised (e.g: mobile) format databases It is said that this is a trivial transformation and that format could be kept closed if data is also provided in an open format. Ok but how to be sure that data provided in Open Format is exactly the same than the one contained in closed format ? by example how to check that non-OSM data have not been included in closed format ? To make a parallell ( perhaps wrong ), GPLv3 requires that someone providing a binary using GPL code must provide the source code ( including modifiactions if any ) eveything needed to rebuild the binary. "Both versions of the GPL require you to provide all the source necessary to build the software, including supporting libraries, compilation scripts, and so on. They also draw the line at System Libraries: you're not required to provide the source for certain core components of the operating system, such as the C library." source: http://www.gnu.org/licenses/quick-guide-gplv3.en.html and "GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device." Do the ODBL requires the same for a closed format including OSM data ? or more clearly does it require that application provider also provide the tool used to perform the conversion between OSM data and closed format ? If yes, by consequence this would allow user to be independant of application provider and to regenerate by itself the maps directly from OSM data. If this topic has already been covered somewhere sorry and I'll please you to provide me some pointers to the discussion Thanks by advance for you answer Cheers Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM down?
De : Glenn Plas Same here. There is indeed an issue on www.openstreetmap.org According to this site http://www.downforeveryoneorjustme.com/www.openstreetmap.org www.openstreetmap.org is up Cheers Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
De : Simon Poole That is completely incorrect, there was never any Australian government CC by-SA data in OSM. The data in question was licensed CC by which required permission from the respective offices that attribution via our website was acceptable, the permission was duly granted. Ok sorry I missed ( or forgot )the conclusion of this point, thanks for the clarification/memory refresh Cheers Julien___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
De : Martin Koppenhoefer Share alike licensed data should IMHO not be imported into osm because it makes another license change practically impossible (at least not without data loss, and unfortunately not only the originally imported data but also everything built on it). Hi Martin, IMHO your sentence is incomplete, my understanding is that you intended to say "Share alike licensed data should IMHO not be imported into osm because it makes another license without share-alike clause change practically impossible (at least not without data loss, and unfortunately not only the originally imported data but also everything built on it)." Migrating to a licence keeping the origin "free" spirit of OSM should not be a problem Cheers Julien___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
De : Tobias Knerr Hi Julien, the relevant part of the CT was introduced so that OSM would not have to suffer such a painful loss again. Ideally, it should be possible to decide on a license change purely based on the merits of the proposed new license. Hi Tobias In my understanding this prevent only the loss of data contributed by no more active contributor. For me there is nothing related to an incompatiblity with data licence source. There have been quite a few rights holders who have given OSM such an explicit permission, so it might be worthwhile to just ask them. If I remember well Australian government didn`t agree to mirgate the data they provided from CC-by-SA to ODBL so this is not so simple But what I'm clearly opposing is importing data with a share-alike license - that is, a license that demands that we stick with one single license forever. According to CT terms ( cf below ) I assume that a new licence should maintain the share-alike of ODBL Extracted from : http://www.osmfoundation.org/wiki/License/Contributor_Terms 3. OSMF agrees that it may only use or sub-license Your Contents as part of a database and only under the terms of one or more of the following licences: ODbL 1.0 for the database and DbCL 1.0 for the individual contents of the database; CC-BY-SA 2.0; or such other free and open licence (for example, http://www.opendefinition.org/okd/) as may from time to time be chosen by a vote of the OSMF membership and approved by at least a 2/3 majority vote of active contributors. ) Cheers Julien___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France "BANO" project... openaddresses in France
De : Tobias Knerr À : talk@openstreetmap.org Envoyé le : Jeudi 15 mai 2014 17h51 Objet : Re: [OSM-talk] OSM France "BANO" project... openaddresses in France The relicensing clause is there for a reason: The community in 10 years will mostly consist of completely different persons than today. And *they* should be able to determine what OSM's license will be in 10 years. Limiting their choices in order to slightly speed up the completion of house number mapping today would be not be wise. Hi Tobias, I don't see this as a problem because if I well understand ODBL requires an attribution so if a relicencing would be proposed in the future it will be possible to list the imported ODBL data and consider to remove them if the new licence is not compatible. By this way the amount of data loss will be an argument pro or against a new licence in the same way some data were loss during the migration from CC-by_S to ODBL due to impossible relicencing To be completely sure to understand you point of view, I will try to rephrase it, please correct me if I`m wrong: You consider that we should completely stop to use any open data sources available in the world because in the future the community will perhaps decide a relicencing that could be incompatible with licences of today legal sources ? It seems to me quite extrem because I consider it implies to keep only our local knowledge and terrain observation Cheers Julien___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
De : Alex Barth Hello everyone - I've been sitting on writing about the detrimental effects of OpenStreetMap's share-alike license (ODbL) for a while and finally decided to, um, share. I've been listening long to many OpenStreetMappers I respect a ton telling me it's not so bad and it's just what we're stuck with right now. But given how bad share alike is for OpenStreetMap I don't think we should give up for pushing for a more open license. Here's why I think share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from having the full impact it could have: http://www.openstreetmap.org/user/lxbarth/diary/21221 Looking forward to your comments, Hi Alex, I disagree with you. Personnaly I contribute to OSM because of the share alike licence. To take you example about Google using OSM data that will increase the community I`m not convinced at all. I think that people would not realize that OSM is behind that and they will only join Google Community to contribute to Google Map data. Without a share alike licence these data will certainly remain in Google DB and not be contributed to OSM one because I wonder what would be the interest of Google to share the data with its competitor whereas it doesn`t do that today. So at the end Google would benefit of OSM data but OSM will not benefit from this usage in my opinion. OSM continue to grow so I don`t see any reason to fallback in a painfull licence change process that will mostly benefit to "consumers" and not to the project itself. This is an endless philosophical debat like the GPL vs BSD in software and I don`t think there is a best solution for everyone. My 2 cents Julien ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM relation ID property in Wikidata
> De : Mike > I guess you are all both right and wrong on this matter and thus because > you are loking from single angle only. > [...] > If object is split, one part preserves existing ID and other parts are > considered as new objects with new ID's assigned. Hi I quite agree with Mike. Properties should have a stable ID and geometrical objects ( way,node,relations) should refer to this ID to be qualified and on the other way it should be possible to find these objects from the ID. By this way it would be easy to refer to a complex object like a motorway or country boundary even if it is made of a lot of subobjects. It would also solve the issue repeating a lot of tags on a lot of objects just because there is one change on part of the way It would be a kind of everything is a "relation" but I'm afraid it could mean a change in OSM API my 2 cents Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: Branding?
-- Le sam. 23 févr. 2013 10:58 HNEC, Simon Poole a écrit : > >The "relatively restrictive" is conjecture by you. > >At least my intention is have a as liberal as possible policy that still >makes it clear that we want usage of the relevant names/marks to be >non-confusing and factually correct (for example we would not want any >of the other actors in the geo-data space using OpenStreetMap as a brand >for their products if they do not contain 100% OSM data). > >Wrt RMS: it suffices to point out that GNU is a trademark of the FSF. > >Simon Hi, In case you are not aware of, Debian has made an announcement about " Debian's hassle-free trademarks" [1] . I think that the problematic is quite similar to the one with OSM branding so it could be perhaps interesting to look at what has been done on their side and check if it can be usefull to reuse some ideas. 1 http://www.debian.org/News/2013/20130301.en.html My 2 cents... Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Qualité des sources de données
> De : Abba Asmaou Hi Abba, I think that your message should be sent to French mailing list ( talk...@openstreetmap.org ) The subscription page is here : http://lists.openstreetmap.org/listinfo/talk-fr Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: RFC - OSM contributor mark
-- Le mer. 16 janv. 2013 20:58 HNEC, Kai Krueger a écrit : >Hi, > >may I throw a related, but slightly different concept, out there for >discussion? > >I think some of the confusion between "contributor mark" and "attribution >mark" is that they may be entirely different things. From the design I have >seen so far it seems indeed more like a "contributor mark" than an >"attribution mark", but you are planning on using it as an "attribution >mark" > >I'll give an example to try and clarify what I mean by "contributor mark" as >opposed to "attribution mark": > >Wikipedia have OpenStreetMap integration into articles. I.e. if you open a >geocoded wikipedia article you can click in the top right corner on either >the globe symbol in e.g. the English Wikipedia or the textual link "Map" in >e.g. the German Wikipedia which opens an inline map into the article showing >the place based on an OSM map. > >There were considerations on adding an "edit" link to the map, as it would >a) be fitting to Wikipedia and b) help OSM gain new contributors as it can >capitalize on the huge user base of Wikipedia. > >However, one concern with adding an edit link was to explain to the >Wikipedia user why after clicking on the edit link they suddenly landed on >this "odd" page called OpenStreetMap which wants a new user name and >password from you. How does this relate to Wikipedia where they actually >wanted to be? What is the concept behind OpenStreetMap? How and what can I >edit? > >So the idea was to redirect first time map editors (not logged into OSM and >don't have an OSM cookie) via an explanatory contributor page before sending >them to the editor page. > >To Wikipedia users the concept of users editing the content is already >familiar, but on many other third party sites that use OSM maps, the >relation between the page they came from and OSM is likely even less clear >to users. > >Therefor having people redirect through a explanatory page would be even >more helpful. I think the contributor page as presented here could be a >really nice basis for such a page. > >So instead of replacing attribution, the contributor mark is an additional >component acting as a well recognizable "edit this map" button with the >underlying explanatory page for new contributors. > >OSM could then encourage everyone who uses OSM maps to add this contributor >mark / button to really try and capitalize the growing share of OSM users >into new mappers by providing a more user friendly integration. To Website >providers this would also be a benefit, as with including a few lines of >simple html / javascript, they can help improve the maps they are using and >identify them selves as real supporters to the OSM movement. > >In that case imho the size and design of the current proposed "contributor >mark" is much more appropriate than as an "attribution mark" > >Thoughts? > +1 Very interesting idea Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: OpenStreetMap Future Look
-- Le mer. 9 janv. 2013 13:26 HNEC, Paweł Paprota a écrit : >Projects like OSM do not run on fairy dust and rainbows. Yesterday I >watched Jimmy Wales (founder of Wikipedia) on The Colbert Report talk >show and he was talking about Wikipedia's strategy and budget. They >spend nearly 30 million dollars a year on hardware, network, manpower >(technical, administrative) just to keep Wikipedia running. Of course it >is not nearly the same scale as OSM but the same principle starts to >apply to OSM as I hope everyone wants OSM to be more like Wikipedia in >terms of users and being well-known. The number of core contributors >stays pretty much the same for two years now. > Hi Pawel, Since few months I read several articles saying that wikipedia loose contributors (due to more and more constraint it seems to be harder to contribute) and I also see quite a lot of criticism in forums from people complaining about cost of manpower in wikipedia compared to hardware and network costs. I love wikipedia and the idea of participative common encyclopedia but the fact that some people think that there are negative points like mentionned above, is very painfull and make me feel that wikipedia is perhaps not a so good model in term of organisation..I hope this will never happen for OSM and that the main words used by external people to talk about OSM will continue to be fun,passion,community etc hug and thanks for mappers,users,developers and all people involved in osm Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New History tab for openstreetmap.org (beta)
Hi Pawel, Could it be possible to integrate the user classification visible here ( http://resultmaps.neis-one.org/oooc) by example by adding the same coloured man icon on the right of OSM User link. IMHO it could be very usefull to know if an edit has been done by a new user of a senior user my 2 cents Julien > > De : Paweł Paprota >À : talk@openstreetmap.org >Envoyé le : Vendredi 4 janvier 2013 0h01 >Objet : [OSM-talk] New History tab for openstreetmap.org (beta) > >Hi all, > >For some time now I've been working on the OpenStreetMap Watch List project[1] >and on integrating OWL into the main OSM website. > >At this point I've got something slowly approaching beta status and I would >appreciate early feedback from the community. > >You can see it in action here: > >http://owl.apis.dev.openstreetmap.org/ > >Couple of things: > >* Zoom levels >= 14 should be usable. On lower zoom levels it sometimes takes >a lot of time to show history. Also I don't have clear idea yet what to really >show on the lower zoom levels - what would be useful - so suggestions are >welcome. > >* I'm actively working on this instance so don't be surprised when something >breaks or there is no data at all etc. - it's a beta version :-) > >* You can click on nodes/ways in the map to get more details about changes :-) > >Any comments are welcome. > >[1] http://wiki.openstreetmap.org/wiki/OWL_(OpenStreetMap_Watch_List) > >Paweł > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk > > >___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New History tab for openstreetmap.org (beta)
Very nice feature ! Julien > > De : Paweł Paprota >À : talk@openstreetmap.org >Envoyé le : Vendredi 4 janvier 2013 0h01 >Objet : [OSM-talk] New History tab for openstreetmap.org (beta) > >Hi all, > >For some time now I've been working on the OpenStreetMap Watch List project[1] >and on integrating OWL into the main OSM website. > >At this point I've got something slowly approaching beta status and I would >appreciate early feedback from the community. > >You can see it in action here: > >http://owl.apis.dev.openstreetmap.org/ > >Couple of things: > >* Zoom levels >= 14 should be usable. On lower zoom levels it sometimes takes >a lot of time to show history. Also I don't have clear idea yet what to really >show on the lower zoom levels - what would be useful - so suggestions are >welcome. > >* I'm actively working on this instance so don't be surprised when something >breaks or there is no data at all etc. - it's a beta version :-) > >* You can click on nodes/ways in the map to get more details about changes :-) > >Any comments are welcome. > >[1] http://wiki.openstreetmap.org/wiki/OWL_(OpenStreetMap_Watch_List) > >Paweł > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk > > >___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: How to improve addressing?
-- Le ven. 28 déc. 2012 10:47 HNEC, Frederik Ramm a écrit : >Hi, > >On 11/12/12 14:56, Russ Nelson wrote: >> What if the Presets/Annotation/Addresses dialog box wasn't modal (like >> the relations editor, where it lets you continue to edit), and had a >> "Apply and Increment" button? Then you could go down a row of houses >> (once you've verified that they're consecutively numbered), and >> deposit a pre-made house with Control-V, then hit "Apply and >> Increment" to store an address into it. > >I've added an auto-increment facility to JOSM's address preset dialog. It's >kind of experimental, and included in josm-latest as of a few hours ago; happy >to hear feedback on that. > >It solves only half of your problem - you'd like to avoid opening and closing >the preset dialogue all the time as well - but maybe it's a start. > Hi, There is also the same kind of feature in French cadastre JOSM plugin. it handles both tag and relation based schematic for adresses,you can configure increment/decrement step and you just have to select node or ways to apply tags. Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ebook maps
> De : Hendrik Siedelmann > In the > corners of every page are the page numbers of the next zoom level for > the respective quadrant. At the endpoints of the cross that is visible > at every page, there are the page numbers for north/south/... Sorry I missed these numbers... Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] ebook maps
> De : Hendrik Siedelmann > Hello, > all possibilities to render maps as ebooks (or for print) that I found were > relatively limited (only raster images and/or limited number of pages). > So I tried something new: >https://technik-stinkt.de/~hendrik/maps/ > What do you think? Hi Hendrik, This is a good idea, but I`m not able to see any index or glossary in your example pdf. The medium example is composed of about 2500 pages, how can I know on which page to go to find the location I need ? On map book there are also often some marks on page sides/corners to indicate the page number we have to go if we want to have left/right/up/down part of the map. Could you add such information ( if it could be in form of hyperlink it would be nice )? Some pages are also completely grey. could you eliminate them from the book ? Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
> De : Paul Norman > If the French community has contact info (email preferred) for someone who > speaks both English and French and is willing to take on dealing with > contacting users and getting them to use dedicated accounts I'd welcome it. But you already have it ( Christian Quest ;and Sly sly (sylvain letuffe) ;). They have proposed to make the link between DWG and French Community Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
> De : Martin Koppenhoefer > My French is a bit rusty but I think that this is the crucial part: " > non soumise aux droits patrimoniaux d’auteur" > Now compare to this paragraph: > http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation#La_r.C3.A9ponse_de_la_DGI > "En revanche, la rediffusion de ces données n'est autorisée que pour > les produits composites, c'est à dire ceux constitués pour partie > seulement du plan cadastral, et sous réserve que soient clairement > indiqués l'origine et le millésime des données cadastrales utilisées" Hi Martin, it means that we cannot distribute raw data coming from Cadastre alone. We are allowed to distribute them only if they are part of composite dataset/work ( = mixed with data coming from other sources ) and only if we add to them the information that they are coming from cadastre and the year of cadastre ( = our tag source= Cadastres 2012 ) So the integration in OSM with the source tag by French contributor made them part of a composite dataset with cadastre attribution so this is fine. PS : I remove talk-fr from cc as people are complaining about non french mails Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)
Hi Martin, You forgot to put the French list in cc > There is generally a problem with entering data for which you are not > the full rights holder and which is not in the PD. The data you > import/merge has strings attached (requires attribution which may not > be removed) which might lead to removal of the data in the case the > active contributors choose to switch to a more open license (e.g. > cc0), so it is very important that this data is easily identificable. I was thinking that this issues was addressed by the CT providing all rights to the OSMF for data added to OSM. Am I wrong ? > Maybe > on the server side we could allow several OSM accounts for the same > email adress (not sure if this is already the case, but from former > discussions I remember that this was one of the concerns)? I test it few minutes ago and I confirm this is not possible. IMHO this is an issue. best regards Julien > > De : Martin Koppenhoefer >À : winfi...@gmail.com >Cc : osm ; d...@osmfoundation.org >Envoyé le : Jeudi 18 octobre 2012 13h10 >Objet : Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French >contributors (cadastre integration) > >2012/10/18 Jo : >> The French are integrating the data of the cadastre, their surveys, their >> local knowledge and Bing aerial images to improve Openstreetmap.org as a >> whole. They are not doing a bulk import that needs to be sorted out later >> on. >> The local community's opinion should be more important in this matter, than >> the opinion of one person in the UK and the DWG should wield its power to >> block actual acts of vandalism, instead of annoying good contributors. > > >please also see the other side's motivation: there is good reason not >to put meta data into the main database but on a changeset level, >still your local guidelines apparently lead to filling the global >database up with source-tags: >http://taginfo.openstreetmap.org/keys/source#values >(There are roughly spoken more than 7 times cadastre source-tags than >there are for example source=bing tags) > >There is generally a problem with entering data for which you are not >the full rights holder and which is not in the PD. The data you >import/merge has strings attached (requires attribution which may not >be removed) which might lead to removal of the data in the case the >active contributors choose to switch to a more open license (e.g. >cc0), so it is very important that this data is easily identificable. > >The guidelines for imports are clear (use distinct account, make an >information page in the wiki). IMHO this is not a very complicated >requirement, but I agree it could - on a technical level - be made >easier to manage multiple accounts. Maybe someone of the French >community (or someone else) has the time and expertise to code an >extension for JOSM which would allow to change between multiple >accounts on the fly or assign the edits of the same session in the >editor to different accounts while editing and on upload this would >automatically create several changesets (one for each account)? Maybe >on the server side we could allow several OSM accounts for the same >email adress (not sure if this is already the case, but from former >discussions I remember that this was one of the concerns)? > >Cheers, >Martin > >___ >talk mailing list >talk@openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk > > >___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: RE: Réf.: Re: All you've ever wanted to know about the french cadastre
-- Le ven. 28 sept. 2012 08:00 HAEC, Paul Norman a écrit : >> From: THEVENON Julien [mailto:julien_theve...@yahoo.fr] >> Sent: Thursday, September 27, 2012 10:14 PM >> To: penor...@mac.com; cqu...@openstreetmap.fr; si...@poole.ch >> Cc: talk@openstreetmap.org >> Subject: Réf.: Re: [OSM-talk] All you've ever wanted to know about the >> french cadastre >> >> >> Le ven. 28 sept. 2012 02:13 HAEC, Paul Norman a écrit : >> >> > >> >Obviously buildings are part of it, but is there a list of what else? >> > >> >> Hi, >> >> I don't think there is a list. >> the information that you can find are highway references,street >> names,city boundaries,cemetery boundaries,buildings,house >> number,hydrographic layer(this one is not really reliable so must be >> cross check carrefully with other sources),railways. >> only buildings railways cemetery boundaries and hydrographic shapes are >> automatically extracted. Other information must be read by contributor >> in cadastre overlay because automatic solutions are not reliable at the >> moment > >How do people know what features they can import without going through >additional consultation as a new import? > sorry this detailled here in section les differents calques wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Français/Aspects_techniques_du_cadastre_en_ligne and here qu est ce qui est reutilisable wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Français/Conditions_d'utilisation cheers julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: All you've ever wanted to know about the french cadastre
-- Le jeu. 27 sept. 2012 20:18 HAEC, Sarah Hoffmann a écrit : >> This is the real problem for us. > >For the sake of completeness: planetwide there are currently >152 million objects. Which means 1/6th of the planet consists of >French buildings. Now, there is a real problem. > Hi Sara, concerning problem of disk usage by french cadastre data do you have some information?particulary do you know how is it stored in database? to be allowed to use cadastre data we have to add a source key which is long about 40 characters to each way drawn thanks cadastre data due to legal agreement with french office goverment providing cadastre data. do you know is this key is duplicatd for each building in the database or if there is a smart storage? if not it would be interesting to know which part of the size is for the key itself and which part is for the geometry. I think that for buildings composed of one way and 4 nodes the space required by the could be greater than for geometry. if this is the case there is perhaps a way to factorise the source key and dramatically reduce disk usage. Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: All you've ever wanted to know about the french cadastre
-- Le ven. 28 sept. 2012 02:13 HAEC, Paul Norman a écrit : > >Obviously buildings are part of it, but is there a list of what else? > Hi, I don't think there is a list. the information that you can find are highway references,street names,city boundaries,cemetery boundaries,buildings,house number,hydrographic layer(this one is not really reliable so must be cross check carrefully with other sources),railways. only buildings railways cemetery boundaries and hydrographic shapes are automatically extracted. Other information must be read by contributor in cadastre overlay because automatic solutions are not reliable at the moment Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
> De : Sarah Hoffmann Hi Sarah, Sorry for this late response and hope to make debate less passionate. > I don't know which data you have been looking at, but let's ask Nominatim, shall we? Great idea, this is always good to discuss about facts Ok, so by example could you extract stats from Grenoble instead of whole France ? I thinks this quite representative of cities where there are buildings and quite a lot of details. Concerning discussions about separated accounts I`m sure that there is a good reason behind that but it was perhaps decided for cases that do not match French one. What we are trying to do here is to discuss to understand why this rule has been done ( that's why we are asking for a list of issues that import Guidelines Rules want to address ) and if it is possible to find a solution both satisfy the goal you have and that do not create problems for good-will french mapppers that spend time to perform clean cadastre integration. I`m convinced ( or at least I hope )that you don`t create this rule to make French mappers crazy. Concerning the waste of bandwidth and CPU, the nuisance for people who want to use OSM data I understand the problem but I guess it will come even without cadastre because due to Open Data mouvment there will certainly more and more big data sources to integrate. There is certainly something to do also with tools or database schematic perhaps to optimise this kind of issues but agains I think that cadastre is the thing that put the light on the problem but is not the direct cause of the problem. We are mapping the world and I think this quite surprising to have only 32 bits id ( I face this kind of problems in my professional life with long microelectronics simulations ) but this is certainly due to good reasons when it has been designed and I understand the issue you mention. So if cadastre building integration create technical issues like too many disk space usage or lack of technical solutions to solve the issue you mention I would prefer that you say that clearly and ask to stop cadastre import until there is a solution rather than saying use separated accounts or things like that won't solve your issue. I`m really happy that you mention a technical problem and something concrete to explain clearly one part of the problem and I thinks that Fench community is able to understand this kind of problematic. Thanks for your food for thought and I hope that we will succeed to reach a solution Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
> De : Lester Caine > The 'two accounts' is a bit of red herring here - in my opinion - but similarly JUST uploading buildings is pointless? Not at all. This is the heart of the problem for a lot of french contributors !!! as already mentionned raw building import is the expection but you are focus on it. For major part of French contributors we are adding buildings and other details not related to cadastre, so having one account per kind of edit will be really painfull.. but it it will not be for people that just perform raw building imports ! This is the real problem for us. We are also discussing a French Cadastre Task force to avoid raw building import withtout needed corrections but this is an other topic Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
> De : Lester Caine > Looking at the imagery or some other source if you are an arm chair mapper, > or driving around with the GPS tracker if you want a run in the country. > THEN adding buildings using the other sources. Even just looking at what is > available on potlatch for France, there is sufficient 'missing' detail to keep many people busy, and raw imports of cadastre to my mind are not helping! > They should just be used to add a little more detail when appropriate? Every people contribute for their own reason and so have their own priorities... some cares about roads some not, some care about the world with low detail level, some care about small region micro-mapped Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
>De : Martin Koppenhoefer > +1, usually (at least in some cities I checked) "housenumbers" are > identifying a whole parcel (exceptions exist), IMHO better then > assigning them to a single house as Simon suggested it would be to add > them to the whole parcel (I guess you have these also available in > France, haven't you? In the end that's what a cadastre is about...) In French cadastre you normally have a number for each parcel ( that we do not put in OSM ) House number is something different and only some parcel contains buildings associated to house numbers ( 0, 1 or more ). Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
>De : SomeoneElse >Maybe it's a work in progress: >http://www.openstreetmap.org/?lat=43.99103&lon=0.33956&zoom=15&layers=M Or there are some people that think this is a good way to highlight where some roads are missing. Personnaly I prefer to draw roads and building at the same time to have more complete maps Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
De :Jean-Marc Liotier Because the cadastre work is an armchair mapping process whereas the address tagging requires local survey. They are often done by two different type of contributors. On top of that as the cadastre distinguish light buildings and buildings, house with terrasses and veranda etc are represented by several buildings but there is still a single house number ( if it exists ) Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
De : Simon Poole > Supposedly the cadastre includes street names and house numbers, however of the 27 million buildings (plus 6 million wall=no) only a minuscule number have further information attached, matter of fact there are more nodes with addresses tagged in France than there are building outlines with house numbers. Why this is the case, I don't know, but house numbers etc. would be of far more immediate benefit to our data than just building outlines. Some people put the house number on a node located where there is the building entrace ( and sometimes forgot to tag the entrance) Sometimes there are several house number on big buildings so house number is place on nodes instead of buildings. Some people prefer to place the number where it is located physically, near the street when an house has a long alley A lot of buildings outside cities does not have house number appearing in cadastre. This kind of reason can explain what you are observing Cocerning building outlines it can be usefull for people performing study about urbanisation density etc so there is not one benefit related to one cateogry of data but benefits related to use. Since we started to massively draw building outlines we also observe in France that people put much more POIs because this is very easier to add them when you have the buildings instead of just street because you know nuch more that your baker is just after 3rd building than 23meter after street corner... The main interest of opendata is to allow unexpected usage so IMHO this is an error to decide in advance what has benefit or not for everyone Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
De : Lester Caine Many of the buildings moving away from the one identified simply do not even fit the footprint on the bing imagery ? What make you so sure that the thruth is in imagery and not in cadastre ? particulary considering that Bing is often several year late and that offical french maps (IGN) are also relying on cadastre for building ? There are a lot of examples of places where there are some buiding referenced in cadastre that do not appear in Bing but that you can see IRL. You will decide to remove them because you they are not on Bing or you will trust local contributors that introduce them because they know they are real ? how do you make the difference between the guy that has the knowledge and the one that has not ? Now that I have scanned some of the French material I must say that it is of very low quality and all of the stuff I have reviewed needs at least SOME work to bring it up to a better standard. At best all one can say currently is 'there are some buildings round about here' ... and stripping unsubstantiated detail would at least be a start. According to the way you say that I assume that you have directly check in IRL or perform a comparison with a better quality and reliable source to decide that the wole cadastre is of very low quality... Could you share with us you criteria and methodology to be so affirmative and allow us to determine which details are unsubstantiated ? After all we are just mappers that concentrate on part of world where we are living and that we know, if I remember well this is the base of Openstreetmap crowdsourcing ? Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: All you've ever wanted to know about the french cadastre
-- Le mer. 26 sept. 2012 21:48 HAEC, Lester Caine a écrit >Looking at the source material, there is nothing which can be used to separate >the blocks displayed into separate buildings, and since we have no means of >identifying different levels of building, adding 'detail' for that seems >pointless? All that can be 'accurately' extracted from the source material is >that there is a 'block' of buildings? So if you are not actually surveying the >buildings and identifying individual buildings, then normal practice is to >draw a single box. Frederik's example is the sort of thing that SHOULD have >been tidied up before importing. please don't forget that you are talking about something that is considered as a bad import by the french community and that you are currently focusing on one building whereas there thousand correct buildings imported by hardworking mappers. you also seem to consider that there is only cadastre in the life. majority of contributos also use there local knowledge. I personnaly know where buildings are separated in my city and where there is a single one or at least I can go to check directly. I don't know by heart the number of level for each building and I have other priority at the moment(I prefer to concentrate on missing roads by example) but I think it would have no sense to remove correct details provided by cadastre just because I cannot had the details at the moment. a mappers keen of micro mapping or osm2xp will just have to add the missing details if he want. Please don't consider that what you think useless is useless for everyone. few weeks ago we had a request from a guy that would like to use osm data to compute solar energy potential production. For the moment this not possible but it can be done by adding some tags to separated adjacent building to indicate orientation of roof. by keeping only the external shape of building block it will not be possible > >Hand tracing hundreds of individual elements and not committing them often >does not make sense. What I am talking about here is selecting hundreds of >vectors from a file without checking them, and having to select each >individually would help the checking process. Then perhaps the sort of >questionable mapping demonstrated would not happen? >Personally I would prefer to see >http://www.remote.org/frederik/tmp/funnybuilding.png as a single closed >outline box. If the vectors are not providing closed objects then there is >something wrong with the data anyway and in my book it should not be allowed >to be imported? With a decent editor, one should be able to select the outline >of a block and simply import that ... where did you see open building objects ? cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
De : Lester Caine Now that I understand what is going on, I can see where some off the 'extra' lines come from, and the diagonal is probably due to a boundary detail from changing sheets. This is more often due to split of landuse ownership. There is no differences between this lines and the one separating adajacent buildings However while the source has two different shades of block for buildings. I don't think they can be used at this stage to provide useful extra lines. The process that is extracting the vectors should further process the data so that each block IS a single continuous outline? Later comparison will then be easier as long as say 90% of the area matches the previous instance? No this is not sufficiant I think because some times you have adjacent buildings that are not a single building. You also have cases when line separate building parts which have different number of levels or which are "light buildings" ( without wall by example ) Of cause simply importing thousands of these objects without a visual check of every one of them is something completely different to hand tracing every one of them. I'd prefer that there was some cross check that objects have been verified. And in my book, having to manually select objects to import would provide that check? So I'd block any area select function, so that hundreds of objects can't simply be picked and pushed? Please also notice that this is sometime not easy to distinguish on aerial imagery if the split line really exist or not. Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] All you've ever wanted to know about the french cadastre
De : Frederik Ramm To give an example, look at this imported building http://www.remote.org/frederik/tmp/funnybuilding.png Note how the main building consists of 8 separate parts plus a strange diagonal line, and note how the smallest parts are just about 2 metres wide. Compare to the aerial image: http://binged.it/UuYSio A very careful tracer of the aerial image might indeed have created more than just one shape for this, but there is hardly anything there on the imagery that suggests *such* a complex edifice. This is not an example that you only find after a long search; it is a typical cadastre import building. It could also have been done by a guy manually drawing on top of cadastre without cross check with aerial imagery...(Ok it will make a smaller volume if manually done) In any way using a separated account or add some tags will not prevent this case. Do you think it will make their detection easier ? Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
De : Lester Caine Sees the light :) Great ! SO while we have this type of raster data from as a background in potlatch and josm and some elements of it in vector files from OS and other sources. You are having to stitch together 'pictures' and then your 'automatic processing' is recreating vector data from the 'pictures'? I don`t know all details but yes this is something like that I understand the problems now ... and it only really works because the pictures can be simply vectorised. yes has pdf is vectorised but if i rember well what you see as a simple yellow rectangle is an overlay of different rectangle inside pdf code explaining partly why we have some geomtry problems with contigous buildings. SO I would be asking if the 'pictures' can be merged to create a single raster overlay for France to use as a background 'source' which could potentially be used to trace from, but can be used in conjunction with BING imagery to corss check? The French cadastre licence doesn't allow us to redistribute cadastre data as they are so I think it is not legally possible to do that. The other issue is related to projection : Mercator for Bing and Lambert 9 zones for French cadastre. In addition to that not all the french cities have vectorised cadastre data. There are still a lot of cities which have raster data that are just scan of cadaster paper plan without georeferencing ( Feurs in 42-Loire by example ) I would classify that as my base import since it's not externally available? We have several versions of the OS data along with the historic maps for the UK, and I feel sure that should be achievable in France as well? I don't know if some people are interested in historic maps or such kind of map aspects in french community The vectorised files are the 'staging layer' and I'm sure that since you are providing each building as a shape then in the future it should be possible to maintain a 'building_id' that can be used with the sort of merge tools I am looking for to handle this type of data? We have a tool called "bati fusion" that try to perfom a diff between OSM files to make merging easier by using building shape comparison I think but I don`t know if it is massively used. I personnally know the guy who developped it if you are interested Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
De : Lester Caine But I'm still not clear if that is done of a properly geo-referenced overlay/layer? The initial automatic process would be creating that layer although I would accept that keeping historic versions is something that could be a cost that nobody will cover? yes the automatic process create a properly geo-referenced OSM file available on cadastre.openstreetmap.fr How is the cadastre.openstreetmap.fr data structured? Please refer to my previous email ( 13:07 ) if you have not read it at the time you wrote this email. I you need more details about it please quote the part of text which is not clear, it will be easier for me to answer ;-) It sounds as if this IS the base import of the cadastre data? So what is missing is a 'staging' layer, which identifies what has been imported. I presume that the current view is that it's this 'automation' that is not practical yet? There are such tools for administrative boundaries of cities but not for buildings. If I remember well nobody mentionned this kind of need up to now has the process is manual normally user should perform the import if data are already there. But the 'extra' tools being provided simply allow large blocks of raw data to be copied over once they have been identified as building or what ever?No the problem with automated tool is that generated building data are sometimes artificially splitted due to the fact that cadastre landuse is splitted according to landuse ownership whereas in reality building is not splitted. You also have some case where OSM data has been draw on top of Bing that was not precisely georeference compared to cadastre so you need to adjust data. Sometimes water coming from cadastre doesn't exist in real life so that's why we need to perform manual check Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
>>>> De : THEVENON Julien >>>> You can have cadastre has overlay in JOSM using french cadastre plugin. >>>> If you want to perform the test on Saint Galmier you will have to install the plugin in JOSM, restart JOSM. Change the projection to "Lambert 9 zones" and choose Lambert CC zone "5", restart JOSM. >>>> In cadastre preferences ( just behind plugin part of preferences dialog window ) choose vector Grab Multplier "100m" thanks to the radio button. Sorry I forgot one step. It is mandatory to first get some OSM data because the cadastre plugin rely on current JOSM bbox to perform request on Official french cadastre servers so Download some OSM data in Saint Galmier region ( to have an idea where it is located http://www.openstreetmap.org/?lat=45.588947&lon=4.315972&zoom=18&layers=M ) >>>> Then in JOSM "Cadastre" Menu choose "Cadastre grab" >>>> In the dialog box type "SAINT-GLAMIER" in Commune field. In department list choose "42 - loire". Click on OK and normally you should slowly have a new overlay >>>> representing french cadastre data. Notice that their are coming in picture format. >>>> I'm not sure about if this is possible to do the same with Merkaartor Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
De : Lester Caine That has been a previous request :) The google translation is a little strange. OK I was not aware about that And if we can automate that process it would help you? The add of source tag is already automatic I'm just repeating things that were being quoted earlier, but I would like to have a look at the data myself to see if we are talking about the same things. Accessing the French data is difficult for a non French speaker :( Ok. So by exemple to see official data goto on www.cadastre.gouv.fr In "Commune" field type Saint Galmier In "Departement" liste choose "42 - LOIRE" Then click on "rechercher" button In "Ville commune" list choose "Saint Galmier 42330" ( I know this is painfull ) Click on "Rechercher" ( bottom right ) Click on "Vue d ensemble de la commune". Normally you should have a pop up window that display cadastre data. You can zoom/unzoom on it using left panel to make details like river, building, streets appear. This is for the official data. The corresponding processed data that you can find on http://cadastre.openstreetmap.fr/data/ are those data downloaded in PDF format processed by a C++ script that analyse geometrical forms and colours to extract buildings, railways, rivers and produced separated OSM files. You have one directory per french department ( in the case of Saint Galmier this is number 42 named LOIRE ) containing all the OSM files of cities belonging to this department. In my example case the data corresponding to what you have seen on cadastre.gouv.fr are located in these files: http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER-city-limit.osm http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER-rails.osm http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER-water.osm http://cadastre.openstreetmap.fr/data/042/I1222-SAINT-GALMIER.tar.bz2 The french wiki cadastre page provide a big warning aout poor quality of water data and the fact that we need to perform some verifications and cleanup of all these data ( building, railways, river etc ) has the analyse is not perfect. I can't access the government data as an overlay? The English translation is a little light, but I suspect this only give hard copy output? IS the raw data available in a manor that we can access directly in a josm or something similar? You can have cadastre has overlay in JOSM using french cadastre plugin. If you want to perform the test on Saint Galmier you will have to install the plugin in JOSM, restart JOSM. Change the projection to "Lambert 9 zones" and choose Lambert CC zone "5", restart JOSM. In cadastre preferences ( just behind plugin part of preferences dialog window ) choose vector Grab Multplier "100m" thanks to the radio button. Then in JOSM "Cadastre" Menu choose "Cadastre grab" In the dialog box type "SAINT-GLAMIER" in Commune field. In department list choose "42 - loire". Click on OK and normally you should slowly have a new overlay representing french cadastre data. Notice that their are coming in picture format. I'm not sure about if this is possible to do the same with Merkaartor The cadastre.openstreetmap.fr seems to a similar problem? I can select a Department and then in some cases Ville, but nothing seems to happen? Please refer to explainations at the beginning of my email and let me know if you are still facing issues There is obviously good data available, and all I'm asking is some help in viewing it. In the same manor as data is being made usable elsewhere ;) The UK's OS data is available as 'layers' we can work with, and it would be nice to see the French data similarly available. We have to process the raw OS data into a raw format that is correctly geo-referenced, and that raw data is available, so I would anticipate that the French data has had similar processing? Is that raw data available anywhere? Having got the raw layer(s) we NOW need to process them into a 'staging' layer which can be used to integrate later updates - all of which should be made available as raw layers - but the staging layer would be the one that flags what has or has not been merged. So I'm not sure if cadastre.openstreetmap.fr is your 'raw data' layer, in which case there should be a 'version select' or your staging layer? The georeferencing is already there for vectorised data of cadastre ( for raster cadastre data this is much more complex than the example I provide to you and we hae no automatic tools at all to 'integrate' them). We have currently no historic versionning. For the other points I`m not sure to understand what you mean so I hope that the explaination on how to access to official cadastre data and processed data will make things more clear Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
De : Richard Fairhurst Because it's not just about scripts and bots. The Cadastre situation, which started all of this off, is often people loading .osm files into JOSM, running a quick validator check over it, and uploading. In terms of impact on the map and on the community, there is no significant difference between this and the same operation using upload.py. What you mention is normally and exception. The french wiki page about cadastre building integration explicitely mention that data should be checked carrefully and merged with the existing to keep database coherency and quality. The french community has also some tools to detect people doing what you mention and often perform a revert of the changeset, contact the contributor to explain that there are some quality requirements. Clean cadastre integration is a process that take quite a long time when done correctly and that could not be automated, that's why it has been decided to not perform a national automated import like CLC but rather to rely on contributors which do that city by city Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
De : Peter Wendorff Yes, it is part of the import process, as it's the main preparation of the import. When we "import" a list of facilities we get from a third party, e.g. the fuel station import last year, most of the time the raw data is not fitting to osm needs very well. Most of the time there's some kind of preprocessing, be it manually or automatically - and if it's done by a bot that bot usually has to be developed, too. All this is part of the import process IMHO, yes Ok, in our case this is done manually during the merge. All versions? No. On cadastre.gouv.fr you have the current version It was said that there are new versions every few years. Do the old, then outdated versions stay there? On cadastre.openstreetmap.fr data are regenerated periodically or on demand Apart from that while OSM basically has English as the lingua franca, I think it's a bad idea to rely on French only for documentation - inside osm as well as for outside documentation like cadastre.gouv.fr. I guess this at been written in french only because it was targeting french communauty for OSM documentation Cheers Julien___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
De : Lester Caine Hi Lester I do get the impression that the Cadastre import has it's own rules on how to use it, and those are only available in French, which irritates. You mean you would appreciate a translation of French Cadastre wiki page ? But it does need to follow the generic rules, which simply allow some tracking of where detail is sourced, and also the accuracy of that data. Every objects coming from cadastre have a tag source mentionning cadastre. This is mandatory and required by French Cadastre to be integrated in OSM We have been getting some information on their process, but I still don't understand some of the problems they are flagging as reasons for the practices? Could you precise which problems you do not understand so we can clarify ? import processes which are simply mapping a data source into a format that can be merged. Concerning French cadastre the manual work to merged the data is quite huge whereas for CLC import it was automatically done. Do you consider that this manual work is part of the import process or not ? I thinks that THIS is another misconception that is causing confusion. To avoid confusion and misconception is there somewhere an exhaustive clear and preceise list of objectives of Guidelines imports rules ? It would be good to have such a list to be sure that we discuss about the same things and the same goals. It would also allow to discuss on facts and technical points and perform an objective evaluation of strengh and weaknesses of various proposal. For the moment I`m not sure that everyone has the same vision of what we are doing and which goals we want to reach. Cadastre is at least two layers, the original raw data, and a processed view of that data from which objects are 'imported' into 'osm'. Both of those layers should be accessible for all of us to at least view The original data are available on cadastre website cadastre.gouv.fr The processed data are available town by town on cadastre.openstreetmap.fr The data after user manual processing in order to solve issues ( coherency with existing OSM data, artefacts not detectable by processing scripts etc ) are the one sent to OSM ( Data coming from cadastre avec source flag) Cheers Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: Proposal for import guidelines
Le mar. 25 sept. 2012 21:22 HAEC, Jean-Marc Liotier a écrit : >I like this proposal - from my very personal point of view it safeguards >all the conflicting interests and reaffirms essential inflexible >principles while cutting some slack to users who perform small local >imports : > >The "bot=yes" tag identifies the import as such, to help moderators >focus on that class of potentially widely damaging changes. > >"bot_url=necessary context about the import, including quality and methodology >issues specific to the source of data. > >The "bot_source_licence" tag clarifies the license status of the source >at that point in time. > >The specific conditions (imports of more than a given number of nodes, >continuously running scripts, edits affecting more than one country) for >changesets for which a separate account is necessary are clear and >non-equivocal, reaffirming the current requirement for a separate >account while letting the users of occasional small-scale imports at a >local level perform them with their personal account. > >The need to keep these conditions open-ended is a weakness that lets >detractors claim that they are arbitrary, but I'm guessing that this is >necessary to prevent users gaming the rules with stupid technical >loopholes... Not quite transparent but practical. > >This proposal hits all the goals I have seen stated so far... Or are >there others that are not satisfied by this proposal ? > >On the French list, some contributors are complaining that the >changeset-level tagging makes the separate account requirement entirely >obsolete. Technically, I believe they are right... But I hope they'll >see that this proposal could be a fair meeting ground for an opportunity >to improve the import process with better metadata and make it more >flexible where necessary while not messing too much with the current >international consensus hi, The proposal of changeset tags seems also good for me but I consider that the arbitrary criteria of node number is a weakness that fall in the trap of "stupid technical loopholes" mentionnedby Jean Marc. it will be quite easy to split changesets to stay under the limit and avoid the use of a separated account. geographical area limitation (by example country scale) could also be hacked by splitting. that's why I personnally think that purely automatic script without manual refinement are better criteria to justify the use of a dedicated account unless there are some other reasons I'm not aware of that make the only use of tags unsufficiant best regards Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
