Re: [OSM-talk] Import guidelines OSMF/DWG governance
On 2012-09-19 05:36, Willi wrote: I really don't like the attitude expressed by several people here in response to this subject and which is already contained in the subject itself OSMF/DWG governance. Governance. There's no governance. DWG is a group and everybody is free to join it. The job is voluntary and unpaid. Being just a mapper I'm more than happy that there are skilled people who help OSMF and the administrators to keep the system running which I gladly can use for free. Of course there is governance. The whole thread came out of this governance: the DWG blocked somebody because he didn't adhere to standards and didn't respond to mails. If that's not governance, then what is? Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Pieren wrote: The one who never made a mistake in JOSM can be the first to throw a stone. *waves* cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Import-guidelines-OSMF-DWG-governance-tp5725810p5726047.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
On 09/19/2012 01:58 AM, Marc Sibert wrote: That's why we need of help of the machines... asta la vista, baby ! No, that is why you need more contributors. Preferably those who know what is actually there in reality. Not people who only remotely map stuff from secondary sources. -- --- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Importing third party data
Lucas Nussbaum wrote: Alternatively, if this was software development, what should probably be done is: 1. commit the raw conversion for the vectorized cadastre, before the cleanup 2. clean up and upload modified buildings after the cleanup 3. add roads, etc. and upload With the growing volume of data that is becoming available under licences that allow us to use them as sources, it IS important that we have a well documented process on how this data can be used and that it's importation is properly managed. A lot of 'data' is only available as raster images, such as the satellite imagery or maps which can be used as trace sources in the various editors. Some contributors do an excellent job of adding these sources as properly scaled and geo-referenced layers, and for many of us the increasing availability of historic maps fully geo-referenced is doing away with the need to 'import' information into the main database - which is a pity. Other data sets area available either as text data or as full vector data. The text data is currently handled on something of a piecemeal basis. Things like 'a list of places of worship' is relatively easy to cross reference, but without a reliable 'url' for the object ON OSM we can't take as much advantage of that data as would be nice. Vector data is a different mater, and it is the handling of this that we are currently 'disagreeing' about? It is the first line above that is the whole problem here. I remember the discussion on the Canadian data but I don't remember if the data set is now being properly referenced? I have access to a layer of data for the UK that we are currently trying to make available as an import source. Some people will not like it being imported, but it sounds like it is the same layer of data as being added in France. The National Land and Property Gazetteer is a complete index of all of the land in the UK and includes a complete list of all identified roads. In theory is has vector data relating to each object in the data set, but THAT layer is of vastly different quality depending on the local authority who are required to gather it. Some do not yet add this data, and OSM has a unique opportunity to fill that hole! If only we were allowed. The current holdup is licensing, but hopefully it will become available and that is being actively worked on. The PROBLEM is managing the integration of that data and more important it's ongoing updates. However the system is DESIGNED to be continually updated, and updates are happening 'internally' on a daily basis. So update sets are sent out ( and I get them for a number of the local councils that I provide services to ) and we apply them to the local copies of the data. Linking that process into a 'mass import' into OSM will be easy, but then providing the back path of 'updates' to NLPG will be more difficult but something which is of mutual benefit. Point 2 above 'clean up and upload modified buildings after the cleanup' should provide OFFLINE a means of identifying the data that has been updated from the previous upload and ideally 'update' the existing object in the database. Then we can spend our time ADDING data to the database rather than throwing it away every time? It is the 'update' process which we are currently disagreeing on with the French data, and the same discussion happened over the Canadian. Simply wiping existing data and loading a new copy is wrong! Now it may be that the data source does not provide a proper basis to provide managed updates, and that is where the LOCAL groups need to liaise with the sources of the data and help develop a process that allows managed updates. Failing that, then we come back to the 'commit the raw conversion for the vectorized cadastre, before the cleanup' which it WOULD be nice to maintain as an overlay layer, but perhaps it simply needs to be a vector overlay as with other maps sources. Point 3 above is simply wrong 'add roads, etc. and upload' ... and this is the MAIN point about using an account that is identified as an 'import account' ... all of the data added or deleted in that import should relate to the data source! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Pieren wrote: Finally, he decided that the best solution to clean-up the mess was to delete the previous buildings dataset and import the new one. But again, his first intention was to upload the delta only. I will be the first to admit to being a little lax in adding comments to my commits, and rolling things together that should have separate comments. With the volume of commits being made, it is probably not possible for review of every one, but in this case 'Datacleanup' WOULD have been better as 'messed up import, correct upload to follow' ... AND on an account flagged as 'import' it would attract less attention ... but part of the reason that this happened is that the importing of this data needs a little more automated help and that may well mean software to help filter the new dataset prior to even trying to apply it? Of cause the language problem does arise, but much as I hate it google translations can help here although another pet hate of mine is the continuing use of 'English' in the database. In these international times this data should be 'rationalised' so that a simple text_id is stored and displayed against a dictionary for all keys that are well defined - while using the English text as a key can be done, compressing the raw data should be the next target? And I only read English :) Personally I've gone as far as I can with our own 'unusable' data set. I am using it to fulfil my customer requirements, and will be be very active once we get the go ahead to merge it with OSM. So I should probably be offering to help assess what is needed to support the French data import. Except my French is so bad that I'd not know where to start ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
complaining about the quality of his imports. The user was contacted, he didn't react as I understood. There for he was short time blocked. That's a very fair and fine reaction from the DWG. The user was not banned or something, just blocked for short time to gain his attention. And: why should the DWG contact the french community at first? Perhaps, because the user doesn't understand English How do you react if you're blocked by a Chinese, Russian message ? he didn't react Will'you react ? It's an important question for OSM community to have local admin. The more I read this mailing list, the more I see a very central autoritative an non contributor based organisation. Please show me that I'm making jugement mistake, and show me that our work, after beeing uncertain by licence, isn't threatened by centralistic, autoritative, english only person who can set live or dead by non community based decisions. Guillaume DELVIT Democratic OSM French contributor . ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Hi, On 09/19/2012 12:38 AM, Christian Quest wrote: For me a mandatory rule on which someone bases a block decision must be something decided publicly and shared with the community, and clearly published/announced... and none of these has taken place here. Are you saying that we should have had a vote on the wiki, or what? Who would have been eligible to vote? And are you at the same time saying that changing a policy on the wiki is not clearly published? I didn't know about this change until I re-read the wiki page after Marc being blocked. I would not be surprised he was not aware of the now mandatory account that was optional for so long in the guidelines. I'm pretty sure he wasn't aware of that rule. That's why we made him aware of it. Twice. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
guig...@free.fr wrote: Please show me that I'm making jugement mistake, and show me that our work, after beeing uncertain by licence, isn't threatened by centralistic, autoritative, english only person who can set live or dead by non community based decisions. There is a lot of good support available world wide, but perhaps unfortunately the only language many of us can use is English, and it surprises me at times that some discussions on the lists are carried out in better English than I use myself by people who don't even speak it! :) YES we need a little more diversity, but we also need to ensure that the SAME methods are used world wide, and here a 'centralistic' rule base is essential. And on top of that we need to help one another provide the tools that ensure that the 'guide lines' are followed. Alright, this particular 'incident' was not handled perhaps as well as it could have been, and the correct information to make decisions HAS now been made available, but if a request is made then I don't think it is unreasonable to expect someone else who speaks English to help sort out the problem. I've not looked back through the 'history' but it sounds as if we SHOULD have been having this discussion in March? And been helping you at that stage to better manage the use of this data? There is a lot of good expertise available so the one thing we do NOT want is smaller groups doing their own thing :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
2012/9/19 Richard Fairhurst rich...@systemed.net Pieren wrote: The one who never made a mistake in JOSM can be the first to throw a stone. *waves* cheers Richard Richard ! As you're joining this topic, can you explain why you changed the guidelines in the wiki to make the dedicated account a requirement and not a recommendation anymore ? As this been discussed with some other people ? How ? When ? -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
2012/9/19 Frederik Ramm frede...@remote.org Hi, On 09/19/2012 12:38 AM, Christian Quest wrote: For me a mandatory rule on which someone bases a block decision must be something decided publicly and shared with the community, and clearly published/announced... and none of these has taken place here. Are you saying that we should have had a vote on the wiki, or what? Who would have been eligible to vote? And are you at the same time saying that changing a policy on the wiki is not clearly published? We're voting proposed tag scheme. We're discussing them on the wiki and on tagging@ and these are soft rules. Are you saying the same process could not be done for requirements (hard rules) that can lead to blocks when not followed ? So these hard rules are coming from nowhere ? There's no process to set them ? Yes, I'm saying that editing the wiki is not clearly publishing and ANNOUNCING a major change. The wiki is enormous, partly translated (Import guidelines are only available in english and japanese and obviously the japanese translation is not sync as it has been last edited before this new requirement was added in the english version). I didn't know about this change until I re-read the wiki page after Marc being blocked. I would not be surprised he was not aware of the now mandatory account that was optional for so long in the guidelines. I'm pretty sure he wasn't aware of that rule. That's why we made him aware of it. Twice. Yes but if we had been in the loop about deciding this new hard rules, we would have complained at that time and open a discussion BEFORE setting the rule. The rule writing/setting process seems flawed to me. I've been involved in rule writing in international sport competition for 10 years. Changing a rule or setting new ones is something not to do in the shadow, but in the light. Do we have even a list of these hard rules somewhere ? By hard rules, I mean the one that could get a contributor to be blocked or banned. PS: The other problem is that a lot of people are talking about french cadastre imports without knowing exactly how it works, how it is done, the work that's behind, etc. That's why I don't want to go on that part of the discussion, it is another topic that should be split from the governance one. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
On Wed, Sep 19, 2012 at 9:37 AM, Frederik Ramm frede...@remote.org wrote: Are you saying that we should have had a vote on the wiki, or what? Who would have been eligible to vote? And are you at the same time saying that changing a policy on the wiki is not clearly published? To progress a little bit in the debat and clear up some misunderstandings.. It seems that nobody is able to say why the separate user account became suddently mandatory in november when it was earlier a recommendation. Never mind, it was not a problem for us until someone was blocked just for this particular reason, not because it was a good or bad, small or big import. No, just because he did not use a separate account. Some people say just obey to the DWG telling you to follow the guidelines. We say we don't agree with the last change in the guidelines because it does not fit our local practices (some are also saying that the DWG is working beyond his mandate but that's another story). What we explained is that we defined in France our own policy for this particular data source (also on the wiki). We started it years ago. The size of the whole French cadastre dataset is huge. We could upload it in a single mass import with a bot using a seperate user account as we did for the Corine Land Cover. We could follow 100% of the import guidelines. Trust me, we have all the capacities in humans, competences and computers to do it. But instead, we decided that buildings have to be better integrated with the existing data and better controlled by simple, average contributors in smaller chunks. We also decided to exclude major parts of the dataset because it's not usefull for OSM like the parcels or couldn't be well integrated automatically like the roads, street names and address house numbers. We decided limit the import to the railsways, buildings and waterways, we decided to do it at the size of the dataset is itself published, means at the municipality size; it can be a 2 millions inhabitants city or a 50 houses village. We also learned from the previous imports. The French community size is also big enough to manage this kind of crowdsourced import itself. We are not so big as the Germans (but hey, who is ?), we are 2 or 3 times smaller but just the second or third biggest community in OSM. We have servers, we have a local chapter, we have quality assurance tools, we have developers, we have many eyes watching the map and reporting issues to the group, we have one of the most active local mailing list. And we have our own policy to import this dataset where finally the only main difference with the standard guidelines is the separate user account. We are not against it, we can even promote it. We are against making it mandatory. Because we think that all the good reasons provided for this requirement do not apply here. Even some DWG members admit that the separate user account will not be checked for small imports. They are just worry when they detect some stange behaviours or very active users. Themselves, they cannot say when exactly the special account becomes a reason to block someone after how many uploads, changsets or edits. It's only when the contributor enters in their radar tools and after some arbitrary decision. What we ask is not much. We ask that the DWG is taking into account the local communities and their local import policies when it is done with all the good will and sincerity. But we also have our black sheeps. We also need the DWG for blocking users when it is necessary. But let the local community decides when and who. And for that, we need to contact people in their speaking language, not in English, either through a local representative or e.g. standard messages previously translated. Then check with the local community if or what goes wrong with the person and only at the end, suspend his account. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Christian Quest wrote:
As you're joining this topic, can you explain why you changed
the guidelines in the wiki to make the dedicated account a
requirement and not a recommendation anymore ?
As a few people have already said (Michael, Frederik, Simon etc.) this was
basically codifying existing best practice; there was a widespread
understanding among the worldwide community that this was the way to do it.
At the time, I recall that we were having difficulties with a succession of
bad, unregulated and undocumented imports from newcomers - time dulls the
memory but I think there were several in Canada.
It's also been observed, quite rightly, that the nuances of British English
- which tends to gently suggest when other languages would say you
MUST!!!?!1 - are not easily appreciated by non-native speakers. We had a
case on talk-gb at a similar time where the wiki explained don't do it
with typical British understatement; a chap of Polish origin completely
misunderstood this, imported some unwanted data (in the UK) without
discussion - and incorrectly - and then got very aggressive when challenged.
Firming up the language is an attempt to avoid this type of
misunderstanding.
The Cadastre 'imports' are an unusual case, and the enthusiasm with which
Marc has taken to them is more unusual still. Clearly someone who just
traces building outlines in their village should not need to set up a
dedicated account just for that. On the other hand, an import of 115 948
nodes (changesets 12758927, 12759290, 12759667) is heavy-duty stuff on a
TIGER/Canvec scale, and the community consensus - outside France, at any
rate - has generally been that a separate account is required for this.
It's an interesting question as to whether local practice trumps general
community consensus. But I would caution against taking this concept of
'subsidiarity' too far. It's great when global norms are extended within the
spirit of OSM: for example, the German community has adopted the additional
tag motorroad=yes because OSM's long-established highway tagging didn't meet
their needs, and I applaud them for this.
But if, for example, the Moldavian community decided not to use
highway=motorway/trunk/primary at all, but chose road=1/2/3 instead, this
would damage every consumer, every newcomer, and lead to fragmentation and
unnecessary complexity. Saying the local community has decided this can
potentially lead to fossilisation: a group of 50 experienced users establish
a way of working that suits them, but which may not be in the interests of
newcomers. It isn't a silver bullet. (It's a similar situation to some of
the more relation-heavy tagging concepts that are introduced, whose users
then get annoyed when well-meaning newbies come along and inadvertently mess
them up.)
I think there are two things we can take from this.
Firstly, the status of the import guidelines needs to become less ambiguous.
At present we have three largely overlapping policies ('Mechanical Edit
Policy', 'Automated Edits code of conduct', and 'Import/Guidelines') on the
wiki, which are not always easy to find or understand. These need to be
abbreviated into one short, simple, unambiguous document, one that reflects
both the majority will of the existing community and OSMF's responsibility
to encourage future mappers, and then signed off by the OSMF board.
Secondly, we've just finished the licence change and I realise that some
people might miss the arguments... but could I gently suggest (there's that
British English reserve again) that a debate is more likely to reach an
amicable resolution if carried out in a less combative fashion? Assume good
faith and all that. Rabble-rousing on talk-fr@ to say come to talk@ and
argue with people is not really helpful, though I will admit to laughing
out loud at
http://lists.openstreetmap.org/pipermail/talk-fr/2012-September/047956.html
:) A friendly this policy doesn't accord with our local practice, can we
work something out? message to start the thread would have been less likely
to get people's backs up than a long screed with a series of pointed
questions at the end.
cheers
Richard
--
View this message in context:
http://gis.19327.n5.nabble.com/Import-guidelines-OSMF-DWG-governance-tp5725810p5726103.html
Sent from the General Discussion mailing list archive at Nabble.com.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Anglo (- Dutch) translation guide (was: Re: Import guidelines OSMF/DWG governance)
On 2012-09-19 12:04, Richard Fairhurst wrote: It's also been observed, quite rightly, that the nuances of British English - which tends to gently suggest when other languages would say you MUST!!!?!1 - are not easily appreciated by non-native speakers. We had a For this I always use the (completely accurate) Anglo - Dutch translation guide. In light of this discussion, especially note point 5. I'm sure dutch can be replaced with any other nationality. British say: I hear what you say British mean: I disagree and don't want to discuss it any further Dutch understand: He accepts my point of view British say: With the greatest respect... British mean: I think you are a fool Dutch understand: He's listening to me British say: That's not bad British mean: That's very good Dutch understand: That's poor or mediocre British say: Quite good British mean: A bit disappointing Dutch understand: Quite good British say: I would suggest... British mean: Do it or be prepared to justify yourself Dutch understand: Think about the idea but do what you like British say: Oh, by the way... British mean: The primary purpose of this discussion is.. Dutch understand: This is not very important British say: I was a bit disappointed that... British mean: I'm most upset and cross Dutch understand: It doesn't really matter... British say: Very interesting.. British mean: I don't believe you... Dutch understand: They are impressed British say: I'll bear it in mind British mean: I will do nothing about it Dutch understand: They will probably do it British say: I'm sure it's my fault British mean: It's your fault! Dutch understand: It was their fault! British say: That's an original point of view British mean: You're an idiot Dutch understand: They like my ideas! British say: You'll get there eventually British mean: You don't stand a chance in hell Dutch Understand: Keep on trying, for they agree I'm on the right track Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
On 19/09/2012 12:04, Richard Fairhurst wrote:
[..]
Thanks for the level-headed recapitulation - looks like we are moving
forward.
Firstly, the status of the import guidelines needs to become less ambiguous.
At present we have three largely overlapping policies ('Mechanical Edit
Policy', 'Automated Edits code of conduct', and 'Import/Guidelines') on the
wiki, which are not always easy to find or understand. These need to be
abbreviated into one short, simple, unambiguous document, one that reflects
both the majority will of the existing community and OSMF's responsibility
to encourage future mappers, and then signed off by the OSMF board.
Sounds reasonable. Is there an habitual OSM way to set up the working
group necessary to produce such document ? You can of course count on
the input of the French community.
debate is more likely to reach an amicable resolution if carried out in a
less combative fashion? Assume good faith and all that.
With a collaborative process working toward a policy document, all the
energy that poured out in debate will find a productive outlet.
I am sorry if you felt that some of us have been a bit too vindictive,
but the cadastre integration process represents such an amount of manual
processing that some of those who did it took understandable personal
offense that their work could be seen as just another botched mass
import. If their input can be taken into account in the drafting of an
inclusive policy covering massive edits, I'm sure that we'll soon be
over that episode.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Pieren wrote: But let the local community decides when and who. And for that, we need to contact people in their speaking language, not in English, either through a local representative or e.g. standard messages previously translated. Then check with the local community if or what goes wrong with the person and only at the end, suspend his account. A thought here which I think would work ... One of the problems in some areas of the planet is working out which language to use to correspond, and while I can set that for my own account I can't see it on others? Perhaps a preferred language on the users info page? Personally ( not limited to OSM ) when I receive an email from a contact who is obviously struggling I'll resort to google to send a 'translation' in what I think is the language they would prefer. It does help resolve confusion most of the time and can break the ice with the 'strange' use of technical terms ;) On a second level, we are probably at a point where the 'check with the local community' should include copying this sort of matter to them? So the addition of a 'local community' selection would also help? It COULD help direct people to local language based support when they first register? And the local news list would get a post when someone joined who may need help? My data processing hat says He selected French ... what French lists are registered so I can list them. 'Location' could add or filter the results? On the specifics of the 'WikiProject France/Cadastre' ... while I can use Google to read up on the projects progress, it is only really a competent French speaking mapper who can provide an English translation that is accurate? We do not do languages well ... that is a simple fact ... but it does require a little cooperation to fix that. I'm still not sure if the Cadastre data has the necessary unique identifiers to properly manage ongoing imports? The http://wiki.openstreetmap.org/wiki/Import/Catalogue entry is under 'One time import' and has not been updated since 2009 and provides a couple of broken links. This just needs tidying up a little with current information perhaps a summary in English? Even the Cadastre site provides an English version, but only for some of the content :( INFORMING the rest of the community what is going on is one of the 'requests' from the guide, and I'm sure I'm not alone in feeling that this has fallen a little behind in this case? That said, the whole Catalogue *IS* due for an overhaul :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Anglo (- Dutch) translation guide
On 19/09/2012 12:17, Maarten Deen wrote: On 2012-09-19 12:04, Richard Fairhurst wrote: It's also been observed, quite rightly, that the nuances of British English - which tends to gently suggest when other languages would say you MUST!!!?!1 - are not easily appreciated by non-native speakers. We had a For this I always use the (completely accurate) Anglo - Dutch translation guide. In light of this discussion, especially note point 5. I'm sure dutch can be replaced with any other nationality. British say: I hear what you say British mean: I disagree and don't want to discuss it any further Dutch understand: He accepts my point of view ... etc I love it, spot on. [Meaning: I love it, spot on.] Mike A Brit abroad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Anglo (- Dutch) translation guide (was: Re: Import guidelines OSMF/DWG governance)
On 19/09/12 at 12:17 +0200, Maarten Deen wrote: On 2012-09-19 12:04, Richard Fairhurst wrote: It's also been observed, quite rightly, that the nuances of British English - which tends to gently suggest when other languages would say you MUST!!!?!1 - are not easily appreciated by non-native speakers. We had a For this I always use the (completely accurate) Anglo - Dutch translation guide. Or simply use MUST/SHOULD/MAY/... as defined in RFC 2119? http://www.ietf.org/rfc/rfc2119.txt Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
2012/9/18 Jean-Marc Liotier j...@liotier.org: On 09/18/2012 05:42 PM, Simon Poole wrote: The French cadastre imports are, as you know, a rather controversial subject. In my opinion it is a dataset that doesn't actually increase the usefulness of the OSM dataset for most users (building outlines without addresses just don't really help with anything) Building outlines are an essential component of topographical maps, which have all sorts of uses. Buildings are an essential feature of flight simulator scenery that does not look dead. Building outlines help in identifying the position of localities. Even if you believe that OSM is only about roads, building outlines help in pointing to where ways may be missing. And I'm sure I have missed many other uses. +1, building outlines also help to interpret urban typology, they are useful when it comes to surveying housenumbers or ubicating POIs at there correct spot, ... cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Martin Koppenhoefer wrote: The French cadastre imports are, as you know, a rather controversial subject. In my opinion it is a dataset that doesn't actually increase the usefulness of the OSM dataset for most users (building outlines without addresses just don't really help with anything) Building outlines are an essential component of topographical maps, which have all sorts of uses. Buildings are an essential feature of flight simulator scenery that does not look dead. Building outlines help in identifying the position of localities. Even if you believe that OSM is only about roads, building outlines help in pointing to where ways may be missing. And I'm sure I have missed many other uses. +1, building outlines also help to interpret urban typology, they are useful when it comes to surveying housenumbers or ubicating POIs at there correct spot, ... And at this point the mechanism for applying updates from the data source becomes more important? Still having to pull apart 'road-centric' data in the local area where everything is linked to the one way, I have no worry about adding this sort of data. It makes adding details like 'footpaths' as their own elements rather than some vague tag on a roadway meters away from it. Provided that we all follow the same rules when adding this sort of fine detail. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
2012/9/19 Jean-Marc Liotier j...@liotier.org: the cadastre integration process represents such an amount of manual processing that some of those who did it took understandable personal offense that their work could be seen as just another botched mass import. If their input can be taken into account in the drafting of an inclusive policy covering massive edits, I'm sure that we'll soon be over that episode. I'd like to raise another question in this context: citing the source. It seems that you generally apply the source-tag to the osm object instead of the changeset comment, but I'd propose to do it the other way round. There are already tens of millions of objects in the db with related source-tags http://taginfo.openstreetmap.org/search?q=source+%3D+cadastre-dgi-fr and putting it into the changeset comment could possibly reduce the size of the objects tables in the db. This leads also to another question: how should a mapper deal with these source tags when he applies modifications to the object? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Source as attribute of object or changeset ? [was: Re: Import guidelines OSMF/DWG governance]
On 19/09/2012 15:58, Martin Koppenhoefer wrote: It seems that you generally apply the source-tag to the osm object instead of the changeset comment, but I'd propose to do it the other way round. There are already tens of millions of objects in the db with related source-tags http://taginfo.openstreetmap.org/search?q=source+%3D+cadastre-dgi-fr and putting it into the changeset comment could possibly reduce the size of the objects tables in the db. This leads also to another question: how should a mapper deal with these source tags when he applies modifications to the object? I suggest inheritance of source from the changeset, unless overridden by the object's source tag : let the changeset have an optional source attribute that applies to all the changeset's objects that do not have a source tag. Editors such as JOSM could display a virtual source tag that contains information from its changeset's source attribute if it is present. Have such schemes been proposed before ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
2012/9/19 Pieren pier...@gmail.com: The size of the whole French cadastre dataset is huge. We could upload it in a single mass import with a bot using a seperate user account as we did for the Corine Land Cover. We could follow 100% of the import guidelines. Trust me, we have all the capacities in humans, competences and computers to do it. But instead, we decided that buildings have to be better integrated with the existing data and better controlled by simple, average contributors in smaller chunks actually looking at the summary in the osm wiki it looks as if you can't do so for legal reasons: Les données du cadastre ne peuvent former à elles seules les données OSM. Ce qui interdit un import massif, direct et automatique top of the page, 2nd paragraph, Il y a deux conditions à la réutilisation des données du cadastre:: http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Import guidelines proposal update
Hi,
I've read the rather long thread Import guidelines OSMF/DWG governance and
I'd like to propose a change on the wiki page :
http://wiki.openstreetmap.org/wiki/Import/Guidelines
(you can also read and comment on my proposal change on the talk page if you
wish to keep this list trafic lower)
From :
== Use a dedicated user account ==
Create a new user for the import. You must not use your standard OSM user
account. The user page for the account should be used to collate data
relating to the source and contact details for the import. Furthermore, it
means that attribution can often be carried in the account's display name, or
in the account's user page, which is better than putting it as a tag, as the
user's editing history is a permanent record of the source and doesn't
interfere with tags or increase the size of the database as much. For these
reasons, creating a dedicated user account is preferable to using a {{Key|
source}} tag.
To :
== Most imports need a dedicated user account ==
For all fully automated imports, you must create a new user for the import
and not use your standard OSM user account. The reasons are : ease of
control, identification, information about the source and also blocking the
account as fast as possible in case something goes wrong. Furthermore, it
means that attribution can often be carried in the account's display name, or
in the account's user page, which is better than putting it as a tag, as the
user's editing history is a permanent record of the source and doesn't
interfere with tags or increase the size of the database as much. For these
reasons, creating a dedicated user account is preferable to using a {{Key|
source}} tag.
The [[Data Working Group]] , volonteers in charge of detecting broken data
imports, may decide to block your account in case of non respect of that
rule.
In the case of regionaly limited imports (inside a country), it is highly
recommanded to get in touch with the local community to discuss your planned
import and ask them if you should, shouldn't or must use a dedicated account.
In some cases other written guidelines may exist for specific kind of
regional imports that you must follow. You should then add in your
changesets's comments a word/link explaning that you are importing following
this or that guideline in order for surveillying people to understand what
kind of import you are doing and what kind of guidelines your are following.
--
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
Le 19/09/2012 16:23, Martin Koppenhoefer a écrit : 2012/9/19 Pieren pier...@gmail.com: The size of the whole French cadastre dataset is huge. We could upload it in a single mass import with a bot using a seperate user account as we did for the Corine Land Cover. We could follow 100% of the import guidelines. Trust me, we have all the capacities in humans, competences and computers to do it. But instead, we decided that buildings have to be better integrated with the existing data and better controlled by simple, average contributors in smaller chunks actually looking at the summary in the osm wiki it looks as if you can't do so for legal reasons: Les données du cadastre ne peuvent former à elles seules les données OSM. Ce qui interdit un import massif, direct et automatique It means : You cannot make a map with only data from cadastre. You can only mix them with other data. And in fact there is already other data in OSM, so we could... And in fact we don't have a proxy with cadastre data reprojected in WGA84. top of the page, 2nd paragraph, Il y a deux conditions à la réutilisation des données du cadastre:: http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation ;-) 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
Re: [OSM-talk] Import guidelines proposal update
I believe that dedicated accounts are generally better for imports than using mixed ones which are also used for original data. This really helps a lot in sorting data according to its intellectual properties holders. The only exception I could possibly see is data that doesn't come with strings attached (PD/cc0). Please note that even if you don't simply copy the data from another dataset but do some redactional work on it, it will still remain derived from the original source. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Martin Koppenhoefer wrote: I believe that dedicated accounts are generally better for imports than using mixed ones which are also used for original data. This really helps a lot in sorting data according to its intellectual properties holders. Yes, absolutely. The really obvious example of this is the Polish UMP data, which was licensed CC-BY-SA and could not be kept post-licence change. If dedicated accounts had been used, removing this data would have been relatively easy; in reality, it has been (and continues to be) a nightmare. :( So although I understand the motivation behind sly's suggestion that In the case of regionaly limited imports (inside a country), it is highly recommanded to get in touch with the local community to discuss your planned import and ask them if you should, shouldn't or must use a dedicated account, this approach has proved problematic in the past and I would caution against repeating the same mistake. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Import-guidelines-proposal-update-tp5726210p5726241.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
2012/9/19 Vincent Pottier vpott...@gmail.com: Les données du cadastre ne peuvent former à elles seules les données OSM. Ce qui interdit un import massif, direct et automatique It means : You cannot make a map with only data from cadastre. You can only mix them with other data. Yes, and the interpretation of the French community (as in the wiki) was that this would also make a massive import legally impossible. And in fact there is already other data in OSM, so we could... Does this also mean that you can't render and distribute a map of a small part of OSM data from France, if there is only cadastre in it? Or render a subset of the French OSM data, like all building outlines? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 5:41 PM, Richard Fairhurst rich...@systemed.net wrote: I would caution against repeating the same mistake. I thought that such issue is not possible anymore with ODbl. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Pieren wrote: I thought that such issue is not possible anymore with ODbl. No, the Contributor Terms simply say You are indicating that, as far as You know, You have the right to authorize OSMF to use and distribute those Contents under our current licence terms (1a). If the licence changes to one which is incompatible with the import, OSMF may remove Your contributions from the Project (1b)... and that rather requires being able to identify what these incompatible contributions are. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Import-guidelines-proposal-update-tp5726210p5726248.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 6:06 PM, Richard Fairhurst rich...@systemed.net wrote: Pieren wrote: If the licence changes to one which is incompatible with the import, OSMF may remove Your contributions from the Project (1b)... and that rather requires being able to identify what these incompatible contributions are. So, theoretically, we might have the same issue when tracing from Bing for instance. Should we use a different account for Bing imagery contributions as well, just in case we move later to a licence incompatible with Bing ? Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On 19/09/2012 17:26, Pieren wrote: So, theoretically, we might have the same issue when tracing from Bing for instance. Should we use a different account for Bing imagery contributions as well, just in case we move later to a licence incompatible with Bing ? No, because tracing over Bing isn't the same as importing data. It's producing data from scratch by interpreting an image. There are still legal arguments about this, but there are heavy hints that, providing the TCs of the imagery provider don't forbid it (i.e. Bing doesn't, Google does), no copyright or licence carries across from the imagery to what's traced from it. There are similar issues with using imagery to create data as importing it, but they're related to accuracy, not licensing. -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
2012/9/19 Pieren pier...@gmail.com: So, theoretically, we might have the same issue when tracing from Bing for instance. The only obligation when creating data with the help of Bing aerial imagery is that is has to be a non-commercial editor and that you have to contribute back to openstreetmaps.org (which fortunately seems to redirect to openstreetmap.org). Another example would be the PCN in Italy, who gave us (OSM) the right to derive information from their aerial imagery, but they don't require any attribution or similar, so there is not an issue: the data can be used in OSM under whatever license OSM uses. Don't confuse copying data with creating it (with the help of imagery). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
The really obvious example of this is the Polish UMP data, which was licensed CC-BY-SA and could not be kept post-licence change. If dedicated accounts had been used, removing this data would have been relatively easy; in reality, it has been (and continues to be) a nightmare. :( Although I agree we shouldn't forget the past to avoid repeating the same mistakes but since every cases beeing different, I'm proposing to let local communities decide what they think is good for them. Still, I believe every local community is happily discussing it internationaly to know and learn from other (The french community was, is, and I believe will), but I wish to correct those guidelines to reflect the entrusted power we let in local community's hands. The french community wants a bit of autonomy and be able to block it's own abusing members regarding the cadastre import and following it's own guidelines without interferance for third party that we have considered harmfull both to our community and to the data in the end. this approach has proved problematic in the past and I would caution against repeating the same mistake. I hear you well, this is good to remember, we have thought about all that, but still, we have decided otherwise. Since I'm not a native british speaker, and although I had access on this very list to a special what brit says, brits might think otherwise could you translate me your I would caution against into something related to my proposed change ? - Are you agreeing to self determination of local communities about imports ? - Are you agreeing to the above change of the wiki while still thinking communities should really really use a dedicated account, but, ultimetly could choose not to ? Or, to make it even clearer, can I commit my change to the wiki without starting an edit war with anyone, and if no, with what type of wording change could it be commited ? -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 12:06 PM, Richard Fairhurst rich...@systemed.net wrote: Pieren wrote: I thought that such issue is not possible anymore with ODbl. No, the Contributor Terms simply say You are indicating that, as far as You know, You have the right to authorize OSMF to use and distribute those Contents under our current licence terms (1a). If the licence changes to one which is incompatible with the import, OSMF may remove Your contributions from the Project (1b)... and that rather requires being able to identify what these incompatible contributions are. More likely, and more often, what happens is that a well intentioned mapper uses a source for which he believes he has permission. Imports, then finds out that he didn't have (sufficient) permission for the current license. This has happened many times. Volunteer to discuss this if you've done it yourself, but I'm reluctant to point out your mistakes unless provoked. :-) What has also happened, when cleaning up the inappropriate import, is that the user mixed the import with their regular account. If time has passed since the import, they often have failed memory of the changesets involved, etc. it becomes more of a mess to clean up. So use a separate account for imports. And follow the other guidelines as well. The guidelines make for a better OSM, even if it is slightly less convenient. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On 19/09/12 at 16:24 +0200, sly (sylvain letuffe) wrote: Hi, I've read the rather long thread Import guidelines OSMF/DWG governance and ^^ Note that the use of the term guidelines is problematic by itself. Either they are *guidelines*, that is, things that people SHOULD follow, but it's OK (but not recommended) not to follow them. Or they are *rules*, that is, things that people MUST follow. If the DWG blocks accounts based on *guidelines*, I think that they should be renamed to *rules*. Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Sep 19, 2012, at 12:06 PM, Richard Fairhurst rich...@systemed.net wrote: Pieren wrote: I thought that such issue is not possible anymore with ODbl. No, the Contributor Terms simply say You are indicating that, as far as You know, You have the right to authorize OSMF to use and distribute those Contents under our current licence terms (1a). If the licence changes to one which is incompatible with the import, OSMF may remove Your contributions from the Project (1b)... and that rather requires being able to identify what these incompatible contributions are. I am much in favor of clarifying this passage. It's not even clear what's compatible with ODbL means. We should flat out only allow data to be contributed that - is your own - someone else entrusted to you to be contributed (i. e. a public express permission to contribute someone else's data that is otherwise licensed differently) - only requires attribution but is otherwise open (i.e.: no share-alike data). Public domain data would be a good example. These are btw the principles I personally follow and that many mappers that I talk to recommend. Everything else is grey area and potentially puts OSM into an extremely unflexible position in regards to future adjustments to licensing terms. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Import-guidelines-proposal-update-tp5726210p5726248.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 6:41 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: The only obligation when creating data with the help of Bing aerial imagery is that is has to be a non-commercial editor and that you have to contribute back to openstreetmaps.org The only obligation to use cadastre data is to provide credits and the year of the cadastre data (you can use older versions if you like). The cadastre data can be used in OSM under whatever license OSM uses. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Richard Weait wrote: So use a separate account for imports. And follow the other guidelines as well. The guidelines make for a better OSM, even if it is slightly less convenient. I suppose if a mapper is ONLY using import data then they only need one account? As long as it is flagged as being an account with data based on a single import source? I know that it was identifying where data came from that initiated the use of a separate identified account for that data, so 'Marcussacapuces91' failing to identify that he IS importing data is still a problem in my eyes ... giving the local community some of their own autonomy should not allow them to rubber stamp changes that remove this simply courtesy to other mappers to identify 'importing' over 'mapping'? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 6:51 PM, Richard Weait rich...@weait.com wrote: requires being able to identify what these incompatible contributions are. : What has also happened, when cleaning up the inappropriate import, is that the user mixed the import with their regular account. I agree with that. We can specify in the guideline : Provide by any means the possibility to separate imported data and regular contributions. Of course, it is better if the identification can be automated (required for a massive deletion in case of licence change) in which case a standard source tag is more appropriate than a vague credit in a plain text user account description. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Before we go further with policy edits, perhaps we should make sure that everyone understands the goals and that there is a consensus about them... That will make the resulting rules or guidelines more acceptable. Let's focus on the item that triggered the current debate : the requirement for a separate account when imports are involved. From what I have understood in the recent threads (please correct - or lets put that in some wiki space), the reasons for requiring a separate account when imports are involved are as follow : - Identify the import as an import (itself a sub-class of mass edits) to let moderators focus on that class of potentially widely damaging changes. - Provide context about the import, such as a link to a page clarifying license, attribution, quality and methodology issues specific to the source of data. - Let moderators easily identify all edits derived from a particular source of data, so that they can be processed or reverted if grievous license issues occur with that source. - Let moderators easily identify all edits by a particular contributor, so that they can be processed or reverted if grievous quality issues occur with that contributor. Are there other goals that I have missed ? Once there is agreement on the goals, I believe that we'll find it easier to agree on the means. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Source as attribute of object or changeset ? [was: Re: Import guidelines OSMF/DWG governance]
Have such schemes been proposed before ? Not sure about that. But this is logical and feasible _if_ all added/edited objects in a changeset had/have the same source. I can only say for sure about my own mapping: It would be almost always impossible for me -- except when tracing in areas I've never been to. Other than that my sources are a colorful mix of: survey, knowledge, GPS, GPS-aligned imagery, imageries (Bing, Google 2010 in Haiti, etc). This in a way that is totally impossible to tag to changeset. Other than the showstopper above I also find the source tags of/on objects quite often _very_ useful for estimating the accuracy/reliability of the data in question. It also follows the data through extracts and various outside-the-OSM-universe use, which I think is a good idea. So, I see no good reason for tagging source to changeset (only). Cheers, -Jaakko Sent from my BlackBerry® device from Digicel -- Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta -Original Message- From: Jean-Marc Liotier j...@liotier.org Date: Wed, 19 Sep 2012 16:20:29 To: Martin Koppenhoeferdieterdre...@gmail.com Cc: talk@openstreetmap.org Subject: [OSM-talk] Source as attribute of object or changeset ? [was: Re: Import guidelines OSMF/DWG governance] On 19/09/2012 15:58, Martin Koppenhoefer wrote: It seems that you generally apply the source-tag to the osm object instead of the changeset comment, but I'd propose to do it the other way round. There are already tens of millions of objects in the db with related source-tags http://taginfo.openstreetmap.org/search?q=source+%3D+cadastre-dgi-fr and putting it into the changeset comment could possibly reduce the size of the objects tables in the db. This leads also to another question: how should a mapper deal with these source tags when he applies modifications to the object? I suggest inheritance of source from the changeset, unless overridden by the object's source tag : let the changeset have an optional source attribute that applies to all the changeset's objects that do not have a source tag. Editors such as JOSM could display a virtual source tag that contains information from its changeset's source attribute if it is present. Have such schemes been proposed before ? ___ 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] Import guidelines proposal update
On 20 September 2012 00:41, Richard Fairhurst rich...@systemed.net wrote: Martin Koppenhoefer wrote: I believe that dedicated accounts are generally better for imports than using mixed ones which are also used for original data. This really helps a lot in sorting data according to its intellectual properties holders. Yes, absolutely. The really obvious example of this is the Polish UMP data, which was licensed CC-BY-SA and could not be kept post-licence change. If dedicated accounts had been used, removing this data would have been relatively easy; in reality, it has been (and continues to be) a nightmare. :( I think this is a counter example as it is well known which data is imported, and it is still a nightmare. The imported data is marked in a way that was standard for imports, and continues to be used for local TIGER 2011 imports for example. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
On 19.09.2012 09:05, guig...@free.fr wrote: Perhaps, because the user doesn't understand English please use google translate or any other translating tool available on the web or use a printed dictionary or ... Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
On 19.09.2012 12:04, Richard Fairhurst wrote: As a few people have already said [...] cheers Richard applause for this comment! And to clarify it already now: there is no irony behind this statement. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
th == Tom Hughes t...@compton.nu writes: ecm account block. But historical information such as the number of ecm blocks imposed per week are missing AFAICT (allows people to ecm monitor for admin abuse). th It should be pretty obvious from browsing the block list: th th http://www.openstreetmap.org/user_blocks th th the first page of 20 entries normally covers at least a few weeks. Thanks, this is quite adequate for the purpose I had in mind. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines OSMF/DWG governance
On 19.09.2012 11:22, Christian Quest wrote: We're voting proposed tag scheme. ... or not. Frequently nowadays a new value or scheme is invented w/o voting. No statement by myself whether I think this is good process or not... So these hard rules are coming from nowhere ? There's no process to set them ? Please read the comment of Richard (in the archive: http://lists.openstreetmap.org/pipermail/talk/2012-September/064300.html). Yes, I'm saying that editing the wiki is not clearly publishing and ANNOUNCING a major change. As stated by Richard: the change of the wiki was just a documentation of the best practice used since long term, I would not call this a major change. But to point also on the other issue which started the whole discussion: if someone contacts you because of you behavior (even if it is in a foreign language) you should not completely ignore him. The complete ignorance of any contact (threre have been two or three tries) was the reason for the (short term) block, not the disregard of the guidelines. Best ragards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Sending to imports@ and cc'ing talk@ as that's more widely read than the wiki talk pages. From: sly (sylvain letuffe) [mailto:li...@letuffe.org] Subject: Re: [OSM-talk] Import guidelines proposal update Or, to make it even clearer, can I commit my change to the wiki without starting an edit war with anyone, and if no, with what type of wording change could it be commited ? There definitely is not general agreement at this time that this passage should be changed. At this point any changes to the guidelines may be superseded by the current work to combine the various bulk edit documentation into an OSMF bulk edit policy. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 1:57 PM, Jean-Marc Liotier j...@liotier.org wrote: Before we go further with policy edits, perhaps we should make sure that everyone understands the goals and that there is a consensus about them... That will make the resulting rules or guidelines more acceptable. Since you[1] are trying to revise guidelines that are found to be acceptable across the community you'll also want to be clear about how that is a benefit to the community at large. :-) I'm all for clearing up the multiple documents. But let's be clear on the facts at hand. A group of importers decided that they weren't going to follow the guidelines. Then one failed to respond when approached about a specific guideline. And now a group is upset to find that their self-declared-being-above-the-other-mappers is not widely supported. It would be easier to accept your sudden interest in clarifying guidelines if you'd shown any intention to follow them. Do you know who else asks for exceptions to the OSM guidelines when DWG halts them for non-compliance? - Politically motivated editors. Those who insist that their language must be first or only or default language on a node or road or other object without concern for the on the ground rule or other mappers. - The ignorant. They want OSM to match colors on their favourite device or something so they map all roads as highway=motorway and all grass as leisure=park. - Edit war participants. But it isn't an edit war because they are clearly 'right'. - Motivated capitalists. But I have to remove that competing grocery store in my neighbourhood. I need the business. They all got caught with their hands in the cookie jar. Back to the requirement for an import account. In private conversations, I've heard many explanations about why mappers haven't / hadn't created an import account. Only a few have claimed not to know of the import account requirement. I've combined their responses and made them generic. - Too hard to register with another email. I say use username+osmimp...@yourisp.com if they support it. Alternatively, those concerned in the French community can surely offer their members additional email accounts to support their community. - I don't want to change account settings in JOSM. I say start josm with alternate josm.home directory with your saved credentials. Like: java -Xmx2038M -Djosm.home=/home/username/import -jar /home/username/bin/josm-latest.jar - Cadastre is not an import. Cadastre is an import. Could you do the same thing if there were no Cadastre to import? No, you couldn't. Cadastre is an import. - Cadastre is different; I am careful before I upload. All mappers are careful don't insult the rest of the community. :-) Fixing and reconciling data before upload is the obligation you have when contributing. Cadastre is still an import. - No. I want credit for all of my mapping statistics all in one place. Simplest to fix. UserStat now allows you to combine stats from a group of your accounts. [1] Of course, I don't mean you personally, Jean-Marc. I have no idea of your OSM screen name, if you are a Cadastre importer or if you use an import account. I mean those who have been knowingly ignoring the import guidelines. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On 19.09.2012 17:03, Martin Koppenhoefer wrote: I believe that dedicated accounts are generally better for imports a very clear +1from my side. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On 19.09.2012 18:51, Richard Weait wrote: More likely, and more often, what happens is that a well intentioned mapper uses a source for which he believes he has permission. Imports, then finds out that he didn't have (sufficient) permission for the current license. This has happened many times. Verry good point. Thanks Richard! Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On 19.09.2012 18:42, sly (sylvain letuffe) wrote: Although I agree we shouldn't forget the past to avoid repeating the same mistakes but since every cases beeing different, I'm proposing to let local communities decide what they think is good for them. But only if it is not completely opposed to the consensus and well accpeted practice used since long term by teh rest of the worldwide community. Because there is not a OSM France project and a OSM Germany project and but ONE (!) worldwide OSM project. So there must be some (not a complete) concord, otherwise OSM would not work. Still, I believe every local community is happily discussing it internationaly to know and learn from other From my very personal opinion I always try to follow the international community and not do some special German behavior. There are some very special issues where this can't be avoided. But these are not on basic issues like using seperate accounts but special points (e.g. as already mentioned the use of motorroad == yes) . And that's one reason why I do not only read the talk.de ML but also the international talk ML. And that's also the reason I like to join international events like SOTM where the international community meets. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
rw == Richard Weait rich...@weait.com writes: rw the facts at hand. A group of importers decided that they weren't rw going to follow the guidelines. Then one failed to respond when rw approached about a specific guideline. And now a group is upset to rw find that their self-declared-being-above-the-other-mappers is not rw widely supported. You are being unnecessarily inflammatory, Richard. Noone before you has talked of some mappers being above other mappers; shame on you for framing things in that way. One constructive question which has emerged from the debate (see messages by Frederik Ramm, Richard Fairhurst and Jean-Marc Liotier) is as follows: certain local communities have established, over many years, tools, specialized guidelines and monitoring tools for the use of specific data sources. In some cases these may deviate from the general, broad guidelines for imports/mechanical edits. What criteria should be used to distinguish between - local customs which have no negative impact on the project and allow the project to represent geographically/culturally specific features (eg. motorway=yes in Germany) - local customs which endanger the project globally (such as integrating data from a source whose copyright status is unclear/debatable) with a whole range of intermediate issues, such as the separate-account-for-imports suggestion, where French community consensus is that (given all the points already discussed) the inconvenience and burden on contributors outweigh the claimed benefits. -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Hi, Le 19/09/2012 22:55, Richard Weait a écrit : - Cadastre is not an import. Cadastre is an import. Could you do the same thing if there were no Cadastre to import? No, you couldn't. Cadastre is an import. Cadastre is sometimes an import, sometimes not. Using the same data source, you may upload tons of buildings, or draw a single house thanks to cadastre WMS-like service as a background layer. In the end all buildings, without any difference, will get the Cadastre source tag. For instance : this one is from an import : http://www.openstreetmap.org/browse/way/63994077 this other one was drawn manually : http://www.openstreetmap.org/browse/way/181674272 Both have the same source tag, which is a request from the French Cadastre authority. A reason for a dedicated import account (read above in this topic) is that it helps to make a distinction between data sources in case of incompatibility between the source and a new licence. Let's assume French Cadastre Authority changes its mind and revokes any right to use its data in OSM. Cleaning the database will not consist in reverting changeset of imports, no. The only criteria for removing French Cadastre data will be the value of the source tag. Both buildings above will have to be suppressed. it is not a matter of import here. A lot of contributors mapping in France use Cadastre in such both ways : massive uploads and single edits using the same source. Such a mix make a dedicated account useless in this case. That's why I think that, as you say Richard : - Cadastre is different; and does not apply for a separate account. vincent (first post here, usually on talk-fr) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On 19.09.2012 23:45, Vincent de Chateau-Thierry wrote: The only criteria for removing French Cadastre data will be the value of the source tag. That's a bad idea: if someone for what ever reason just decides to remove (or change) the source=cadastre tag of a object (and don't change anything else) you can't identify the object any more. Or to be more precise: you need to use a lot of effort and check all versions of an object (this means: the whole planet) whether it once had the source=cadastre tag. But thats a lot of work to do. Much (!) more easy to identify all the object is if you can take all object created by a special account = just check the changesets. Checking all versions of all objects is the thing we just went through with a lot of pain and effort: creating and using the redaction bot. And we are all aware that this was necessary but not nice and a lot of unporoductive effort. So let's learn from the past and avoid possible issues in the future that can be done easily with very small aditional effort in the presence. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 10:55 PM, Richard Weait rich...@weait.com wrote: Since you[1] are trying to revise guidelines that are found to be acceptable across the community Could you provide evidences about this ? Since the vast majority of the community does not care about import guidelines, I would like to know how you can be sure about this. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines proposal update
On Wed, Sep 19, 2012 at 10:49 PM, Paul Norman penor...@mac.com wrote: There definitely is not general agreement at this time that this passage should be changed. Could you please point out in archives (wiki or mailing list) where the separate account became generaly agreed ? Or you can simply tell me the communication channel and an approximate date, I will search myself. It is funny to see that general agreement is required when you don't like the change and optional (as Frederik said, we have no voting system) when it's going to your way, Now we have two small groups. None of them can prove general agreement. How can we progress in a constructive way ? Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
Pieren pier...@gmail.com writes: On Wed, Sep 19, 2012 at 10:55 PM, Richard Weait rich...@weait.com wrote: Since you[1] are trying to revise guidelines that are found to be acceptable across the community Could you provide evidences about this ? Since the vast majority of the community does not care about import guidelines, I would like to know how you can be sure about this. I'm mostly a lurker in these discussions, and generally more pro-import than many who participate in import decisions. But I find the 'separate account for import' to be an utterly reasonable (along with the rest of the guidlines), easy to follow rule, and I am boggled by the objections to it. pgpVxIaZdUhH9.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
- Original Message - From: Lucas Nussbaum lu...@lucas-nussbaum.net To: sly (sylvain letuffe) li...@letuffe.org Cc: talk@openstreetmap.org Sent: Wednesday, September 19, 2012 5:59 PM Subject: Re: [OSM-talk] Import guidelines proposal update On 19/09/12 at 16:24 +0200, sly (sylvain letuffe) wrote: Hi, I've read the rather long thread Import guidelines OSMF/DWG governance and ^^ Note that the use of the term guidelines is problematic by itself. Either they are *guidelines*, that is, things that people SHOULD follow, but it's OK (but not recommended) not to follow them. Or they are *rules*, that is, things that people MUST follow. Yes , except for the fact that some of the parts of that part do seem to relate to guidelines, Therefore I suggest : 1) Page Title Import/Guidelines this should be changed to Import/Guidelines and Mandatory Requirements 2) Opening sentences be reworded. The current use of phrases such as there are few hard and fast rules, all this is open to discussion could suggest that the text on the rest of the page are mere suggestions, rather than hard and fast rules. 3) be clear on the page which bits are guidance and which bits are mandatory requirements David If the DWG blocks accounts based on *guidelines*, I think that they should be renamed to *rules*. Lucas ___ 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] Import guidelines proposal update
On 9/19/2012 6:29 PM, Michael Kugelmann wrote: Or to be more precise: you need to use a lot of effort and check all versions of an object (this means: the whole planet) whether it once had the source=cadastre tag. But thats a lot of work to do. Much (!) more easy to identify all the object is if you can take all object created by a special account = just check the changesets. I may be missing something, but the special account has the same problem: any edit that splits an object loses the created-by information unless the history is used. Similarly, any edits change the last-edit owner. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
From: Vincent de Chateau-Thierry [mailto:v...@laposte.net] Subject: Re: [OSM-talk] Import guidelines proposal update Hi, Le 19/09/2012 22:55, Richard Weait a écrit : - Cadastre is not an import. Cadastre is an import. Could you do the same thing if there were no Cadastre to import? No, you couldn't. Cadastre is an import. Cadastre is sometimes an import, sometimes not. Using the same data source, you may upload tons of buildings, or draw a single house thanks to cadastre WMS-like service as a background layer. In the end all buildings, without any difference, will get the Cadastre source tag. For instance : this one is from an import : http://www.openstreetmap.org/browse/way/63994077 this other one was drawn manually : http://www.openstreetmap.org/browse/way/181674272 Both have the same source tag, which is a request from the French Cadastre authority. And the proposed change does nothing to help differentiate between cadastre imports (what the discussion is about) and non-import use of cadastre. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines proposal update
Pieren writes: Could you please point out in archives (wiki or mailing list) where the separate account became generaly agreed ? It's always been generally agreed upon as far as I know. You could look at the wiki and see when the text was first edited to suggest a separate account. I would do it, but I don't give a shit. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Import guidelines proposal update
On Wed, Sep 19, 2012 at 6:43 PM, Mike N nice...@att.net wrote: On 9/19/2012 6:29 PM, Michael Kugelmann wrote: Or to be more precise: you need to use a lot of effort and check all versions of an object (this means: the whole planet) whether it once had the source=cadastre tag. But thats a lot of work to do. Much (!) more easy to identify all the object is if you can take all object created by a special account = just check the changesets. I may be missing something, but the special account has the same problem: any edit that splits an object loses the created-by information unless the history is used. Similarly, any edits change the last-edit owner. Splitting can a problem, yes. It was decided to ignore it during the ODbL change because it difficult to determine and is a pretty miniscule problem at the end of the day. If a way is split but the nodes aren't touched, the way might still get deleted if all the nodes go away. As for the last-edited getting changed, that's why Michael talked about using the changesets. You can download the OSC of the original upload and have a list of all of the imported objects, regardless of the current state of it. If all changesets of a user are known to be from the same import it makes things simple. If you have to wade through thousands of changesets with varying comments... not so simple. Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Fwd: Gebruikersvoorwaarden BAG niet meer van toepassing
En zouden die techneuten dat evt ook op het forum willen delen, of is dat teveel gevraagd? Zie http://forum.openstreetmap.org/viewtopic.php?pid=274222#p274222 ZMW schreef: Is een een techneut die deze BAG data als transparant layer voor JOSM beschikbaar kan stellen? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] N317 via A18
On Tuesday 18 September 2012 21:38:35 Wimmel wrote: Mijn probleem was anders, namelijk twee verschillende soorten wegen, gaan over hetzelfde stukje asfalt. De A18 (highway=motorway) en de N317 (normaal highway=primary). Omdat de highway tag natuurlijk niet aanpas, klopt de betekenis van de ref tag niet als ik daar N317 aan toevoeg. Maar de wiki noemt meerdere soorten ref tags [4]. Met name nat_ref en reg_ref zijn hier van toepassing (resp. nationaal en regionaal). Ik kan dus aan de betreffende wegen nat_ref=A18 en reg_ref=N317 toevoegen. reg_ref wordt bijvoorbeeld in België ook al gebruikt [5]. Echt? Dan zal je vermoedelijk de enige weg in België met reg_ref gevonden hebben... Normaal gebruiken we gewoon ref=*, omdat (E-wegen buiten beschouwing gelaten) elke weg toch slechts één wegnummer heeft (moesten twee stukken samenvallen dan wordt één van de twee onderbroken). Voor E-snelwegen die geen R-wegen zijn gebruiken we ref=E** + nat_ref=A**, voor andere E-wegen gebruiken we ref=R**/N** + int_ref=E**. Daarnaast gebruiken we ook ref=E34-E313 met een koppelteken, omdat dat zo ook op de wegwijzers staat. Ben ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] N317 via A18
On Tuesday 18 September 2012 21:38:35 Wimmel wrote: Mijn probleem was anders, namelijk twee verschillende soorten wegen, gaan over hetzelfde stukje asfalt. De A18 (highway=motorway) en de N317 (normaal highway=primary). Omdat de highway tag natuurlijk niet aanpas, klopt de betekenis van de ref tag niet als ik daar N317 aan toevoeg. Maar de wiki noemt meerdere soorten ref tags [4]. Met name nat_ref en reg_ref zijn hier van toepassing (resp. nationaal en regionaal). Ik kan dus aan de betreffende wegen nat_ref=A18 en reg_ref=N317 toevoegen. reg_ref wordt bijvoorbeeld in België ook al gebruikt [5]. De on the ground-rule. Wat staat er op de verkeersborden en de hectometerpaaltjes? Op de verkeersborden vanaf het noorden staat de N317 alleen tussen haakjes, vanaf het zuiden wel met oranje plaatje. Maar op de autosnelweg staat alleen A18. Dus ik zou alleen A18 aangeven en alleen als er een relatie voor de N317 is het stukje A18 meenemen. Maar ook dat vind ik twijfelachtig. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Aligning steets
On 09/19/2012 04:35 PM, Ross Scanlon wrote: They are not mini-roundabouts if you can not drive over them. Look here: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmini_roundabout Also read the Australian Tagging Guidelines here: wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines mini_roundabout is not determined by size. Australia does not have mini roundabouts, road rules require you to drive around the center island unless it is impractical to do so, ie truck, bus. According to the tagging guidelines for mini roundabout this is one :- http://goo.gl/maps/8WAZ6 Are you saying it isn't? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] suburb boundaries
FYI, Franc was kind enough to let me have a copy of his original Perl import script. Email me if you want a copy. However, and I think Franc would agree, I understand it has really been superceded by the capabilities of ogr2osm. Emilie Laffray said to me in email, If it is done properly (and data is good), ogr2osm would remove duplicate nodes, merges ways etc... A little inspection of data should provide us this. On the discussion of whether it is actually a good idea, my mild suggestion, (I am no longer based in Australia), is that OpenStreetMap schema and so on is becoming stable enough to think about having separate layers outside the main database. This might well suit the suburbs boundary case. Perhaps one as an as is official layer and one as a community-edited version. Mike On 19/09/2012 11:17, Andrew Harvey wrote: Hi Ken, On 19/09/12 11:57, Ken Self wrote: In doing a manual load I am ensuring the boundaries share common boundaries with one another and the multipolygons close off properly. Those are pretty much impossible to do with an automated load. Even a few manual errors creep in but they are easily fixed. As I understand it from the ABS website http://www.abs.gov.au/ausstats/abs@.nsf/0/a9421cdfb258e4a4ca2570ad00818509?o pendocument they are supposed to be the gazetted boundaries ... that document is for the 2006 census boundaries. For the 2011 ASGS, the Non-ABS structures data is at http://www.abs.gov.au/AUSSTATS/abs@.nsf/DetailsPage/1270.0.55.003July%202011?OpenDocument With the documentation at http://www.abs.gov.au/AUSSTATS/subscriber.nsf/log?openagent1270055003_oct%202011.pdf1270.0.55.003Publication469CDA45CE2B94CCCA257937000D966FJuly%20201131.10.2011Previous it states that the LGA boundaries which form part of the ASGS 2011, are an ABS approximation of officially gazetted LGAs as defined by each State and Territory (S/T) Local Government Department. Which is good enough for most purposes, and a good starting point for later corrections. I suppose that raises an interesting point, that in true OSM spirit if on the ground data indicates an area is LGA X (eg. street sign branding), but the official gazetted boundaries say otherwise, OSM should primarily contain what's on the ground, rather than the official one. Again quoting from that document, the suburb boundaries which form part of the ASGS 2011, are an ABS approximation of localities gazetted by the Geographical Place Name authority in each State and Territory (S/T). Since 1996 these boundaries have been formalised for most areas of Australia through a program coordinated by the Committee for Geographical Names in Australasia (CGNA) under the umbrella of the Intergovernmental Committee On Surveying and Mapping (ISCM). SSCs are built from Statistical Area Level 1 (SA1) that, singly or in combination, form an approximation of Gazetted Localities. The question is what to use as a definitive source for corrections that is ODBL compliant. I've found some maps on http://www.vec.vic.gov.au/publications/publications-maps.html#5 but not sure if we can use them to make corrections in OSM to the ABS boundaries. No you cannot gather information from those maps and transfer it into OSM. Those maps are Copyright All rights reserved. And the golden OSM rule is don't copy from other maps unless they are released under a compatible license. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Rest areas
Hi all, I want to draw attention to the correct tag for rest areas, namely highway:rest_area http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area Most I've seen have been tagged as amenity:parking and/or tourism:camp_site. The camp_site tag is wildly misleading, as setting up camp is prohibited in rest areas. I'm fixing these as I come across them. John ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rest areas
On 20/09/12 06:03, John Henderson wrote: Hi all, I want to draw attention to the correct tag for rest areas, namely highway:rest_area http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area Most I've seen have been tagged as amenity:parking and/or tourism:camp_site. The camp_site tag is wildly misleading, as setting up camp is prohibited in rest areas. I'm fixing these as I come across them. Thanks John I didn't know about this. I've just fixed two of these in fosm. *I hope people on this don't see the inclusion of this line trolling. But since we inherit all mapping techniques, tags, and other how to map guides in fosm from osm, it makes sense to consolidate that discussion on the OSM lists, and wiki etc. signature.asc Description: OpenPGP digital signature ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Rest areas
On 20/09/12 08:17, John Smith wrote: The rest area to the south of Gympie allows camping for up to 48 hours or something like that, it's not the only one, but the one I know off the top of my head. I'm aware of a few of those free caravan/camping facilities, sometimes provided by local council to boost trade in a struggling town. I think we'd all agree those should be tagged as tourism=camp_site, along with maxstay=2 days for example. http://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site http://wiki.openstreetmap.org/wiki/Key:maxstay John ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] suburb boundaries
Unfortunately I've found that the ABS data that the data is not as good as it ought to be. Many nodes that should be shared are not coincident and in many cases a vertex node for one boundary has no corresponding node on the straight through boundary. And in some cases the vertex node is not quite on the adjacent way or the ways cross over. I'm finding that as often as not I have to join node to way rather than merge nodes to resolve the boundary intersection Ken -Original Message- From: Michael Collinson [mailto:m...@ayeltd.biz] Sent: Wednesday, 19 September 2012 7:50 PM To: talk-au@openstreetmap.org Subject: Re: [talk-au] suburb boundaries FYI, Franc was kind enough to let me have a copy of his original Perl import script. Email me if you want a copy. However, and I think Franc would agree, I understand it has really been superceded by the capabilities of ogr2osm. Emilie Laffray said to me in email, If it is done properly (and data is good), ogr2osm would remove duplicate nodes, merges ways etc... A little inspection of data should provide us this. On the discussion of whether it is actually a good idea, my mild suggestion, (I am no longer based in Australia), is that OpenStreetMap schema and so on is becoming stable enough to think about having separate layers outside the main database. This might well suit the suburbs boundary case. Perhaps one as an as is official layer and one as a community-edited version. Mike On 19/09/2012 11:17, Andrew Harvey wrote: Hi Ken, On 19/09/12 11:57, Ken Self wrote: In doing a manual load I am ensuring the boundaries share common boundaries with one another and the multipolygons close off properly. Those are pretty much impossible to do with an automated load. Even a few manual errors creep in but they are easily fixed. As I understand it from the ABS website http://www.abs.gov.au/ausstats/abs@.nsf/0/a9421cdfb258e4a4ca2570ad008 18509?o pendocument they are supposed to be the gazetted boundaries ... that document is for the 2006 census boundaries. For the 2011 ASGS, the Non-ABS structures data is at http://www.abs.gov.au/AUSSTATS/abs@.nsf/DetailsPage/1270.0.55.003July% 202011?OpenDocument With the documentation at http://www.abs.gov.au/AUSSTATS/subscriber.nsf/log?openagent1270055003 _oct%202011.pdf1270.0.55.003Publication469CDA45CE2B94CCCA257937000D 966FJuly%20201131.10.2011Previous it states that the LGA boundaries which form part of the ASGS 2011, are an ABS approximation of officially gazetted LGAs as defined by each State and Territory (S/T) Local Government Department. Which is good enough for most purposes, and a good starting point for later corrections. I suppose that raises an interesting point, that in true OSM spirit if on the ground data indicates an area is LGA X (eg. street sign branding), but the official gazetted boundaries say otherwise, OSM should primarily contain what's on the ground, rather than the official one. Again quoting from that document, the suburb boundaries which form part of the ASGS 2011, are an ABS approximation of localities gazetted by the Geographical Place Name authority in each State and Territory (S/T). Since 1996 these boundaries have been formalised for most areas of Australia through a program coordinated by the Committee for Geographical Names in Australasia (CGNA) under the umbrella of the Intergovernmental Committee On Surveying and Mapping (ISCM). SSCs are built from Statistical Area Level 1 (SA1) that, singly or in combination, form an approximation of Gazetted Localities. The question is what to use as a definitive source for corrections that is ODBL compliant. I've found some maps on http://www.vec.vic.gov.au/publications/publications-maps.html#5 but not sure if we can use them to make corrections in OSM to the ABS boundaries. No you cannot gather information from those maps and transfer it into OSM. Those maps are Copyright All rights reserved. And the golden OSM rule is don't copy from other maps unless they are released under a compatible license. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Tasmanian Survey Marks
something that will enable me to check my Garmin 62s' accuracy and give the ability to align Bing when I find them on the ground providing that they can be seen from Bing. Be great if they are in nice circles of I doubt if you'll see them on bing as most survey points are way too small. You'd probably be better of using the agri control points http://agri.openstreetmap.org/download/AGRI_GCP/AGRI_GCP.gdb.csv As these are generally road intersections etc and include photos so can be easier to confirm with bing. Cheers Ross ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Aligning steets
On 19/09/12 19:28, Michael James wrote: On 09/19/2012 04:35 PM, Ross Scanlon wrote: They are not mini-roundabouts if you can not drive over them. Look here: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmini_roundabout Also read the Australian Tagging Guidelines here: wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines mini_roundabout is not determined by size. Australia does not have mini roundabouts, road rules require you to drive around the center island unless it is impractical to do so, ie truck, bus. According to the tagging guidelines for mini roundabout this is one :- http://goo.gl/maps/8WAZ6 Are you saying it isn't? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au Yes it is a small roundabout as you can not legally drive over it unless it is impractical to do so. The vehicle in the street view is clearly about to drive around the center island. Whereas if it was a truck/bus/caravan it would be able to drive over it if necessary. Read through the mailing list archives all this discussion was thrashed out years ago and nothing has changed. Cheers Ross ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] mapas do IBGE e JOSM/PicLayer
Arlindo e demais... Geralmente fico só nos bizus na lista, mas não acho que seja o ideal duplicar a informação, portanto, aqui vai uma sugestã: Deixe que o IBGE se preocupe com o armazenamento dos dados por enquanto. Abra o repositório no github e faça um link através da wiki do git. É menos trabalhoso :D. Abraços 2012/9/19 Arlindo Pereira openstreet...@arlindopereira.com Wille e demais, que tal criarmos um repositório no GitHub com os mapas do IBGE e seus respectivos arquivos de calibração? []s 2012/9/18 Wille wi...@wille.blog.br Olá, Gerald Tenho usado essa técnica, porém eu não sabia desse endereço novo dos mapas no site IBGE e não estava encontrando mais os mapas. Valeu por postar aqui! Muito bom também essa linha de comando do convert! On 18-09-2012 18:32, Gerald Weber wrote: Olá eu não sei vocês, mas eu sempre tive dificuldade em fazer uso dos mapas em pdf do IBGE (http://www.ibge.gov.br/mapas_**ibge/bases_municipais.phphttp://www.ibge.gov.br/mapas_ibge/bases_municipais.php ). Uma solução que achei para isto foi usar um plugin do JOSM chamado PicLayer. Vou passar a receita que estou usando aqui, não sei se é do conhecimento de vocês. No JOSM, selecione editar/preferências e instale o plugin PicLayer. Baixe o mapa em pdf do seu interesse. Eu faço a conversão do pdf para jpg no linux da seguinte maneira (linha de comando) convert -density 300 mapa.pdf mapa.jpg o argumento -density 300 garante que as letras do mapa do IBGE continuem visíveis no JOSM. Se o mapa em pdf tiver mais de uma página ele geralmente cria os arquivos assim: mapa-0.jpg, mapa-1.jpg etc. O convert é um pacote do ImageMagic. No JOSM, posicione as coordenadas mais ou menos na região de onde seria o mapa, selecione a aba PicLayer e carrege o mapa.jpg. Agora vem a parte mais chatinha que é calibrar o mapa. Como os mapas do IBGE vem com as latitudes/longitudes dá para marcar os pontos e arrastá-los. Requer um pouquinho de prática, mas uma vez que está feito ele salva a calibração num arquivo mapa.jpg.cal e fica pronto. No site do PicLayer tem um tutorial de como isto é feito (http://wiki.openstreetmap.** org/wiki/JOSM/Plugins/PicLayerhttp://wiki.openstreetmap.org/wiki/JOSM/Plugins/PicLayer **). Agora uma pergunta: a gente teria algum lugar onde pudessemos depositar os arquivos de calibração? Assim, se o arquivo já existe não seria necessário passar por este passo que é a parte mais trabalhosa. Os mapas do IBGE não são muito precisos, eu não os usaria para desenhar caminhos, mas eles são uma ajuda tremenda para identificar nomes de localidades, rios, serras etc. bom divertimento Gerald __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- George R. C. Silva Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] mapas do IBGE e JOSM/PicLayer
Criei o repositório no GitHub: https://github.com/nighto/calibracao-mapas-ibge Gerald (e demais), você pode colocar lá (ou me passar) os arquivos .cal referente aos arquivos que você já fez? []s 2012/9/19 George Silva georger.si...@gmail.com Arlindo e demais... Geralmente fico só nos bizus na lista, mas não acho que seja o ideal duplicar a informação, portanto, aqui vai uma sugestã: Deixe que o IBGE se preocupe com o armazenamento dos dados por enquanto. Abra o repositório no github e faça um link através da wiki do git. É menos trabalhoso :D. Abraços 2012/9/19 Arlindo Pereira openstreet...@arlindopereira.com Wille e demais, que tal criarmos um repositório no GitHub com os mapas do IBGE e seus respectivos arquivos de calibração? []s 2012/9/18 Wille wi...@wille.blog.br Olá, Gerald Tenho usado essa técnica, porém eu não sabia desse endereço novo dos mapas no site IBGE e não estava encontrando mais os mapas. Valeu por postar aqui! Muito bom também essa linha de comando do convert! On 18-09-2012 18:32, Gerald Weber wrote: Olá eu não sei vocês, mas eu sempre tive dificuldade em fazer uso dos mapas em pdf do IBGE (http://www.ibge.gov.br/mapas_**ibge/bases_municipais.phphttp://www.ibge.gov.br/mapas_ibge/bases_municipais.php ). Uma solução que achei para isto foi usar um plugin do JOSM chamado PicLayer. Vou passar a receita que estou usando aqui, não sei se é do conhecimento de vocês. No JOSM, selecione editar/preferências e instale o plugin PicLayer. Baixe o mapa em pdf do seu interesse. Eu faço a conversão do pdf para jpg no linux da seguinte maneira (linha de comando) convert -density 300 mapa.pdf mapa.jpg o argumento -density 300 garante que as letras do mapa do IBGE continuem visíveis no JOSM. Se o mapa em pdf tiver mais de uma página ele geralmente cria os arquivos assim: mapa-0.jpg, mapa-1.jpg etc. O convert é um pacote do ImageMagic. No JOSM, posicione as coordenadas mais ou menos na região de onde seria o mapa, selecione a aba PicLayer e carrege o mapa.jpg. Agora vem a parte mais chatinha que é calibrar o mapa. Como os mapas do IBGE vem com as latitudes/longitudes dá para marcar os pontos e arrastá-los. Requer um pouquinho de prática, mas uma vez que está feito ele salva a calibração num arquivo mapa.jpg.cal e fica pronto. No site do PicLayer tem um tutorial de como isto é feito (http://wiki.openstreetmap.** org/wiki/JOSM/Plugins/PicLayerhttp://wiki.openstreetmap.org/wiki/JOSM/Plugins/PicLayer **). Agora uma pergunta: a gente teria algum lugar onde pudessemos depositar os arquivos de calibração? Assim, se o arquivo já existe não seria necessário passar por este passo que é a parte mais trabalhosa. Os mapas do IBGE não são muito precisos, eu não os usaria para desenhar caminhos, mas eles são uma ajuda tremenda para identificar nomes de localidades, rios, serras etc. bom divertimento Gerald __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- George R. C. Silva Desenvolvimento em GIS http://geoprocessamento.net http://blog.geoprocessamento.net ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Quo Vadis FOSSGIS 2013
Hallo Tirkon, *Wikimedia-Foundation* und *OSM-Foundation* sind für mich /wesentlich/ eigenständige Organisationen. Sie sollen m.E. nicht vermischt werden. Und schon gar nicht nur deshalb, weil die OSMF (bisher - aber das ändert sich ja gerade) wenig Inhalt, Prozess und Struktur zeigt. Die OSMF ist eine vergleichsweise junge Organisation. Sie braucht den erforderlichen Raum und die Zeit zur eigenen Entwicklung. Ähnliches gilt m.E. für den FOSSGIS e.V. Unabhängig davon, ob und wenn ja welche Rolle er als lokale Vertretung der deutschen OSMer in der OSM-Foundation übernimmt. Dennoch kann natürlich durch mehr und bessere Zusammenarbeit mehr gemeinsame Synergie erzeugt und genutzt werden. Visionäre Vorschläge hast Du ja beschrieben. Fossgis Konferenz der WikiCon anschließen Die zwei Konferenzen haben sehr unterschiedliche Inhalte (Wikipedia und Fotografie einerseits, und GIS und OSM andererseits) und sprechen ein sehr unterschiedliches Publikum an. Es gibt m.W. nur wenige Personen, die sich aktiv in beiden Gruppen bewegen. Andererseits wäre die Verbindung von enzyklopädischem Wissen/Almanach und Geoinformation eine wirklich lohnende Entwicklung für die Vision Freies Wissen für freie Bürger. Daran wird zwar bereits gearbeitet, aber eine bessere Verknüpfung der beiden Projekte ist m.E. wirklich sinnvoll. Die FOSSGIS-Konferenz ist das Aushängeschild des FOSSGIS e.V. Wenn es sie nicht mehr gibt - bzw. nur noch als Bestandteil der WIkiCon - dann fürchte ich eine Bedeutungseinbusse des FOSSGIS e.V. Ich meine, der FOSSGIS e.V. sollte deshalb die FOSSGIS-Konferenz unbedingt selbst durchführen. Und wenn er das 2013 nicht schafft, dann ist das ein guter Anlass, die eigenen Strukturen und Prozesse zu verbessern. Ein wichtiger Schritt zur Verstärkung der Zusammenarbeit zwischen WikiMedia/Wikipedia und OSM wäre eine wirkungsvollere Informationspolitik: sich gegenseitig als Referenten und Teilnehmer auf Konferenzen einladen, über Konferenzthemen und -Ergebnisse berichten, gemeinsame Projekte durchführen, etc. Wikimedia Deutschland ist in der Wikimedia-Foundation der lokale Verein für Deutschland. Bei OSM gibt es keine Entsprechung für Deutschland. Der FOSSGIS e.V. ist ein deutscher Verein zur Förderung von GIS (GeoInformationsSysteme). OSM erhält in Deutschland wesentliche Förderung durch den FOSSGIS e.V. (Server, Konferenzen, Infrastruktur, Geld). OSM wird auch von Wikimedia-Deutschland gefördert (Kooperation OSM Wikipedia, Toolserver). Ich teile die Auffassung, dass diese Förderung ausbaufähig ist und seitens WM-DE begrüsst werden würde. Dabei sollten wir aber m.E. immer unsere Eigenständigkeit wahren. DLF bzw ESA Auch da bestehen m.E. wertvolle Möglichkeiten zur Kooperatoion. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Einträge, vorlage JOSM, roof Tags
Hallo, Am 18.09.2012 um 11:40 schrieb Lars Schimmer l.schim...@cgv.tugraz.at: Dazu eine Anmerkung: das roof:levels tag ist ein wenig, hm, unschön. Da das Gebäude (Keller, Kasten an sich) mit building:levels und building:levels:underground getagt wird, aber das Dach plötzlich mit roof:levels - das fällt etwas raus. Ist da nicht building:roof:levels schöner, einheitlicher? Nein, das passt so wie es aktuell ist. Mehr als einen Doppelpunkt sollte man eh nicht im Key haben, sonst wirds automatisch zu kompliziert. building:levels:underground steht übrigens auch nicht auf der Simple 3D Buildings Wikiseite. Die Seite ist im Prinzip das Ergebnis einiger Diskussionen, die auch auf einem persönlichen Treffen so vereinbart wurden. Jetzt auf ner Mailingliste da nochmal mit der Diskussion von vorne anzufangen finde ich nicht wirklich zielführend. Zu building:parts=* tag ist auch noch ned weit verbreitet, dafür building:part=yes schon. Sieht für mich mal wieder danach aus, als ob jemand meine da nen neuen Tag dafür erfinden zu müssen ohne sich mit anderen Leuten zu unterhalten ob das so sinn macht, oder ob man bestehende Tags dafür weiterverwenden könnte. Man sollte den Tag erst mal einfach nicht verwenden und stattdessen auf building:part=yes ausweichen. Im Wiki sollte building:parts besser als Proposal gekennzeichnet werden (und man sollte den tatsächlichen Vorschlagsworkflow – so wie er jetzt gelebt wird – dort auch mal dokumentieren). MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Einträge, vorlage JOSM, roof Tags
Moin ;-) On 19.09.2012 08:45, Andreas Hubel wrote: Am 18.09.2012 um 11:40 schrieb Lars Schimmer l.schim...@cgv.tugraz.at: Dazu eine Anmerkung: das roof:levels tag ist ein wenig, hm, unschön. Da das Gebäude (Keller, Kasten an sich) mit building:levels und building:levels:underground getagt wird, aber das Dach plötzlich mit roof:levels - das fällt etwas raus. Ist da nicht building:roof:levels schöner, einheitlicher? Nein, das passt so wie es aktuell ist. Mehr als einen Doppelpunkt sollte man eh nicht im Key haben, sonst wirds automatisch zu kompliziert. building:levels:underground steht übrigens auch nicht auf der Simple 3D Buildings Wikiseite. Hm, es gibt einige mit 2 : im Tagnamen, andere mit _ dazwischen, richtig einheitlich isses halt ned. Gewöhnt man sich dran. Der building:levels:underground/... ist im JOSM drinnen und auf einigen anderen Wiki Seiten notiert - und irgendwie auch brauchbar und genutzt. Aber ich hader da noch an was anderem, was da auch in die Quere kommt: Tiefgaragen. Dazu mehr in einem eigenen Thread. Die Seite ist im Prinzip das Ergebnis einiger Diskussionen, die auch auf einem persönlichen Treffen so vereinbart wurden. Jetzt auf ner Mailingliste da nochmal mit der Diskussion von vorne anzufangen finde ich nicht wirklich zielführend. Schon klar - ich wollt das nur mal aufzeigen, ich nutze es ja auch so wie im Wiki geschrieben. Zu building:parts=* tag ist auch noch ned weit verbreitet, dafür building:part=yes schon. Sieht für mich mal wieder danach aus, als ob jemand meine da nen neuen Tag dafür erfinden zu müssen ohne sich mit anderen Leuten zu unterhalten ob das so sinn macht, oder ob man bestehende Tags dafür weiterverwenden könnte. Man sollte den Tag erst mal einfach nicht verwenden und stattdessen auf building:part=yes ausweichen. Der building:parts=* sollte ja nur die Hülle des gesamten Gebäudes umfassen, um zu sagen: das ist ein Gebäude, welches horitzontal/vertikal in kleinere Teilstücke aufgeteilt werden soll. Die einzelnen Teilstücke sind dann mit building:part=yes gekennzeichnet. Im Wiki sollte building:parts besser als Proposal gekennzeichnet werden (und man sollte den tatsächlichen Vorschlagsworkflow – so wie er jetzt gelebt wird – dort auch mal dokumentieren). Ohne mir Arbeit anhängen zu wollen: Ja, es ist ein kleineres Chaos im Wiki, mit 10 Porposal ohne Datum, immer nur achtung, proposal oder ähnliches notiert, aber niergends etwas, was darauf hindeuted dieses ist jetzt das, was wir nutzen wollen, Ausnahme ist die simple 3D Wiki Seite. Aber da fehlt vieles ;-) It´s a hard life. MfG Andi MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mappen von Gebäude mit Tiefgarage, 3D feature Problem!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin! Ich hader etwas mit einem geeignetem Tagging schema für Gebäude mit Tiefgarage. Situationen: 1. http://osm.org/go/0I5UUdblq-- das Gebäude mit Zielpunkt drinnen Da ist unter der gesamten Fläche eine Tiefgarage, so auch gestern eingetragen, mit layer=-1. Darauf halt das Gebäude in verschiedenen Teilen (building:part=yes) für die einzelnen Höhen. Und in der Mitte der Parkplatz, der zum Zielpunkt gehört. Natürlich ohne layer=0, da dieser Wert ja Standard ist. Nun hader ich allerdings, ob das so korrekt ist, wie ich es getaggt habe. Eigentlich gehört die Tiefgarage ja mit zum Gebäude, eigentlich wäre alles zusammen ein building:parts=vertical, und auch die Tiefgarage ein building:part=yes mit building:levels:underground=1 dazu alle anderen Gebäudeteile mit building:levels=1-5 und building:levels:underground=1 Nur wie tagt man dann die Tiefgarage korrekt ? Sie ist dann ja in einzelne Teile zerlegt (jeweils ein Teil auf den building:parts=yes) und kein zusammenhängendes Gebilde. Und wie sagt man, das der Keller im Hausteil eine Tiefgarage ist? Entsprechend stellt mapnik das Haus auch ned da... Hier 2. http://osm.org/go/0I5UUdblq-- Terrassenhaussiedlung Habe ich die Tiefgarage als building:part=yes mit getaggt. Aber hier gibt es die Sorgen mit Layer und Hausetagen. Grundannahme: kein Keller, die Tiefgarage ist ebenerdig und links/rechts der TG sind auch noch Wohnungen/Büros/Ärzte. Nur im Nord-Osten an der Stirnseite ist Erde aufgeschüttet und die Zufahrt geht runter. Auf die TG (Höhe: 1 Etage mit ca. 3m) führt im süd-westen eine Rampe und in der Mitte zwischen den 4 Häusern ist Rasen, 2 Pools, geteerte Wege und Flächen. In jedem Haus gibt es Stiegen, die von der Erdoberfläche bis nach oben gehen. Die Ränder der Häuser (neben der TG) sind Terrassenartig angeordnet und haben unterschiedliche Höhen. Fotos: Eine der Stiegen: http://84.115.129.21/gallery3/index.php/OSM/Terrassenhaussiedlung-Graz/IMAG0265 von der Erde aus, links erkennt man grob die Terrassenstruktur. Das ist das Haus, wo in der Karte 31g/f eingetragen ist. Das Haus 31 vom Kindergarten aus fotografiert: http://84.115.129.21/gallery3/index.php/OSM/Terrassenhaussiedlung-Graz/IMAG0264 Das Haus 35 mit Kindergarten unten links: http://84.115.129.21/gallery3/index.php/OSM/Terrassenhaussiedlung-Graz/IMAG0263 Der Innenhof zwischen Haus 33 und 35: http://84.115.129.21/gallery3/index.php/OSM/Terrassenhaussiedlung-Graz/IMAG0261 vom Eingang im Nord-Osten her gesehen. Mein Plan: viele, viele building:part=yes für die einzelnen Höhen eintragen, über alles ein building:parts=vertical. Nur wie die Tiefgarage eintragen, und wie die Rasen/Pools im Innenhof korrekt eintragen. Und sollt man nen Bugreport an Mapnik senden wegen des fehlenden Hauses vom Zielpunkt-Gebäude und fehlenende Gras im Innenhof? Danke. MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBZeyoACgkQmWhuE0qbFyOVCwCfbmWPuR3B8y3dhtsiTdprtSpm Y3gAmwYzPdVAMpIa/3DOiUcDdRyQBSdj =KokI -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Hallo Ronnie, Am Dienstag, 18. September 2012, 14:46:21 schrieb Ronnie Soak: Das erste Proposal zum Thema extended conditions das mir (von den Tücken der englischen Sprache mal abgesehen) intuitiv genug für den Otto-Normalnutzer scheint und doch auch verzwickte Fälle noch einigermaßen abdeckt. Bitte schaut euch das doch mal an und kommentiert Probleme auf der Diskussionsseite. Abstimmen schadet natürlich auch nicht. Insbesondere die Sicht von Datenkonsumenten fehlt noch ... Aus meiner Sicht ist eine Implementierung nicht übermäßig schwierig. Im Gegensatz zum Extended-Conditions-Proposal ist der Preprocessing-Code des Routers ein bisschen kürzer (in den Conditional Restrictions ist die Reihenfolge schon festgelegt, für die Extended Conditions muss diese berechnet werden). Viel gravierender ist, dass das Schema für Mapper zumindest in den heutigen Editoren eine Katastrophe ist, aber das scheint ja eher ein Randaspekt zu sein. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Viel gravierender ist, dass das Schema für Mapper zumindest in den heutigen Editoren eine Katastrophe ist, aber das scheint ja eher ein Randaspekt zu sein. Kannst du das genauer ausfuhren? Wo siehst du Probleme? Natürlich gibt es momentan noch nichts in den Editoren. Es ist ja auch nur ein Proposal. Aber spricht aus technischer Sicht etwas dagegen? Ein Zeig-mir-das-Schild-ich-generier-das-Tag Plugin wird es ja wohl eh nie geben, aber zumindest gegen einfache Vorlagen spricht doch erst mal nichts. Uhrzeiten lassen sich z.B. gut aus einem GUI Feld in einen Tag übertragen. Gängige Schilder wie 'Land- und Forstbetrieb frei' haben fixe Entsprechungen, können also an das Tag angehängt werden. Schwierig wird es bei Ausnahmen von Ausnahmen, wenn es auf die Reihenfolge ankommt und bei obskuren Freitext-Schildern. Dann wird man über die Handeingabe des Tags aber wohl nicht herum kommen. Oder meinst du bloss, dass die Felder nicht breit genug fur lange tags sind? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von Gebäude mit Tiefgarage, 3D feature Problem!
Hallo, Am 19.09.2012 09:58, schrieb Lars Schimmer: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mein Plan: viele, viele building:part=yes für die einzelnen Höhen eintragen, über alles ein building:parts=vertical. Nur wie die Tiefgarage eintragen, und wie die Rasen/Pools im Innenhof korrekt eintragen. Ich würde hier nur den (Haupt-)Eingang der Tiefgarage eintragen. Alles andere halte ich persönlich für zu viel Aufwand. Und sollt man nen Bugreport an Mapnik senden wegen des fehlenden Hauses vom Zielpunkt-Gebäude und fehlenende Gras im Innenhof? Ich sehe hier keine Bug des Renderers. Wenn du es unbedingt in der Karte sehen willst dann nutze den Layer Tag. Viele Grüße Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
On Wed, Sep 19, 2012 at 10:06:36AM +0200, Eckhart Wörner wrote: Am Dienstag, 18. September 2012, 14:46:21 schrieb Ronnie Soak: Das erste Proposal zum Thema extended conditions das mir (von den Tücken der englischen Sprache mal abgesehen) intuitiv genug für den Otto-Normalnutzer scheint und doch auch verzwickte Fälle noch einigermaßen abdeckt. Bitte schaut euch das doch mal an und kommentiert Probleme auf der Diskussionsseite. Abstimmen schadet natürlich auch nicht. Insbesondere die Sicht von Datenkonsumenten fehlt noch ... Aus meiner Sicht ist eine Implementierung nicht übermäßig schwierig. Im Gegensatz zum Extended-Conditions-Proposal ist der Preprocessing-Code des Routers ein bisschen kürzer (in den Conditional Restrictions ist die Reihenfolge schon festgelegt, für die Extended Conditions muss diese berechnet werden). Wenn die Implementierung nicht schwierig ist, dann könnte sie ja mal jemand machen und dann sieht man ja, wie es damit ist und dann kann man drüber reden, ob man das Schema nutzen und weiterempfehlen will. Diese Abstimmerei über ein Theoriegebäude bringt doch nix. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Hallo Ronnie, Am Mittwoch, 19. September 2012, 10:28:19 schrieb Ronnie Soak: Viel gravierender ist, dass das Schema für Mapper zumindest in den heutigen Editoren eine Katastrophe ist, aber das scheint ja eher ein Randaspekt zu sein. Kannst du das genauer ausfuhren? Wo siehst du Probleme? Natürlich gibt es momentan noch nichts in den Editoren. Es ist ja auch nur ein Proposal. Aber spricht aus technischer Sicht etwas dagegen? Okay, folgendes Beispiel (vereinfachtes Beispiel aus der Wirklichkeit): eine Autobahnbrücke, auf der bei Nässe langsam (80) gefahren werden muss, die Geschwindigkeit wird vor der Brücke schrittweise reduziert: http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm Weil in der Nähe der Autobahn Häuser sind, wird nun beschlossen, von 22:00 Uhr bis 06:00 Uhr eine Geschwindigkeitsbeschränkung von 100 auf dem gesamten Autobahnabschnitt einzuführen. Bitte taggen! Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von Gebäude mit Tiefgarage, 3D feature Problem!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-09-19 10:31, Andreas Dommaschk wrote: Hallo, Am 19.09.2012 09:58, schrieb Lars Schimmer: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mein Plan: viele, viele building:part=yes für die einzelnen Höhen eintragen, über alles ein building:parts=vertical. Nur wie die Tiefgarage eintragen, und wie die Rasen/Pools im Innenhof korrekt eintragen. Ich würde hier nur den (Haupt-)Eingang der Tiefgarage eintragen. Alles andere halte ich persönlich für zu viel Aufwand. Ja, es ist Aufwand. Aber nun, OSM soll ja die Realität abbilden (in verschiedenen Abstufungen), und dank der verschiedenen 3D Renderer kann man daraus ein einfaches, brauchbares 3D Modell erstellen. Das macht es interessant, die Daten detailliert einzutragen (jedenfalls aus meiner Sicht). Und sollt man nen Bugreport an Mapnik senden wegen des fehlenden Hauses vom Zielpunkt-Gebäude und fehlenende Gras im Innenhof? Ich sehe hier keine Bug des Renderers. Wenn du es unbedingt in der Karte sehen willst dann nutze den Layer Tag. Die TG ist bisher layer=-1, somit unter allem anderen. Da ja layer=0 angenommen wird bei jedem Element, das nicht explizit einen anderen Layer tag hat. Somit müssten alle Element gerendert werden. Oder sehe ich das falsch? Viele Grüße Andreas MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBZj2gACgkQmWhuE0qbFyOJKgCfbb6CMqCT6h17AMFNjktsPYNm X2AAn1CSprTTosAazLFNWgnWIDXr0VoH =goik -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Einträge, vorlage JOSM, roof Tags
Hallo, Lars Schimmer schrieb: Der building:parts=* sollte ja nur die Hülle des gesamten Gebäudes umfassen, um zu sagen: das ist ein Gebäude, welches horitzontal/vertikal in kleinere Teilstücke aufgeteilt werden soll. Die einzelnen Teilstücke sind dann mit building:part=yes gekennzeichnet. nein, die Hülle ist immer building=*. Zugegeben, das ist auf der Simple_3D_Buildings-Seite nicht sauber beschrieben aber deine Interpretation les ich da erst Recht nicht raus. Das ist auch im Sinne der Abwärtskompatibilität sinnvoll: Auch wenn ein Gebäude aus mehreren building:part=yes besteht hat man trotzdem noch die herkömmliche building=* Hülle. Gruß, Peda -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: Darstellung der Wanderwege des Harzklubs im OSM
Am 18.09.2012 21:26, schrieb Manuel Reimer: Johannes Hüsing wrote: Dann wäre es ja auch schon strittig, ob man operator=REWE mit beim Supermarkt einträgt. ... oder gar name=REWE... Ich frage mich hier, was das Markenrecht tatsächlich aussagt. Nennen und niederschreiben wird man den Namen ja wohl dürfen. Soweit ich weiß, kann die Nennung einer Wortmarke im geschäftlichen Verkehr nicht untersagt werden (http://dejure.org/gesetze/MarkenG/23.html). Ich darf den Namen nur nicht für einen anderen Wanderweg verwenden. Ich denke der Knackpunkt ist vielmehr die Urheberschaft für den Wegverlauf: § 59 Werke an öffentlichen Plätzen (1) Zulässig ist, Werke, die sich bleibend an öffentlichen Wegen, Straßen oder Plätzen befinden, mit Mitteln der Malerei oder GRAPHIK, durch Lichtbild oder durch Film zu vervielfältigen, zu verbreiten und öffentlich wiederzugeben. Bei Bauwerken erstrecken sich diese Befugnisse nur auf die äußere Ansicht. Also ausdrucken als GRAPHIK darf ich den Wegverlauf, wenn ich die Wege anhand der Schilder selbst erfasst habe. Datenbanken sind aber nicht ausdrücklich erwähnt. Wahrscheinlich muss das ein Gericht entscheiden. Das könnte kurios werden, weil deutsche Gerichte gedruckte Landkarten als Datenbanken eingestuft haben :-) Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Am 19.09.2012 10:46, schrieb Jochen Topf: Diese Abstimmerei über ein Theoriegebäude bringt doch nix. +1 Der GUI ist es doch letztlich nahezu egal, was sie in die Tags schreibt und dem Auswerter ist es auch nahezu egal, was in dem Tag steht (es gibt ein paar Einschränkungen, wie konstante Keys). Egal wie simpel das Schema sein wird, es wird für die meisten Mapper zu kompliziert sein, als das sie es von Hand eintippen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Features von Gebäuden, weclhes Schema?
Hallo, tumsi schrieb: Ein etwas andere Frage, aber zu diesem Thema: Gibt es bereits ein Vorlagen-Addon für JOSM für das 3D-Schema. Ja gibt's :) Schau mal in den Einstellungen unter den Objektvorlagen. Da gibt es die 3D properties von Kendzi (der Entwickler von Kendzi3D und auch ein Unterstützer und Mitverantwortlicher für die Simple_3D_Buildings). Einfach mit dem Pfeil nach rechts aktivieren und JOSM neustarten. Oder ist das Tagging-Schema noch nicht stabil genug, als dass sie das lohnt? Spätestens seit dem zweiten 3D Workshop in Garching würde ich das ganze als stabil bezeichnen. Wird ja auch genau so von den 3D-Entwicklern unterstützt. Und da man es gar nicht oft genug erwähnen kann, eine Möglichkeit deine Daten auch mal visualisiert zu sehen gibt's auf http://maps.osm2world.org ;) Gruß, Peda -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Hallo aighes, Am Mittwoch, 19. September 2012, 11:28:37 schrieb aighes: Der GUI ist es doch letztlich nahezu egal, was sie in die Tags schreibt und dem Auswerter ist es auch nahezu egal, was in dem Tag steht (es gibt ein paar Einschränkungen, wie konstante Keys). Egal wie simpel das Schema sein wird, es wird für die meisten Mapper zu kompliziert sein, als das sie es von Hand eintippen. Das halte ich jetzt für eine nicht ganz zutreffende Verallgemeinerung. Ich glaube nicht, dass maxspeed:wet=80 zu kompliziert ist, um von Hand eingegeben zu werden. Es wird eher so sein, dass eine GUI das letzte ist, was kommt. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Okay, folgendes Beispiel (vereinfachtes Beispiel aus der Wirklichkeit): eine Autobahnbrücke, auf der bei Nässe langsam (80) gefahren werden muss, die Geschwindigkeit wird vor der Brücke schrittweise reduziert: http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm Weil in der Nähe der Autobahn Häuser sind, wird nun beschlossen, von 22:00 Uhr bis 06:00 Uhr eine Geschwindigkeitsbeschränkung von 100 auf dem gesamten Autobahnabschnitt einzuführen. Bitte taggen! auf den Stücken vor und hinter der Brücke: maxspeed:conditional = 100 @ (22:00 - 06:00) Auf den bei Nässe reduzierten Stücken: maxspeed:conditional = 100 @ (22:00 - 06:00); 80 @ (wet) Die detailiertere Bedingung wird jeweils hinten angehägt. Es gilt bei Nässe nach 22Uhr als 80. Soll stattdessen 100 gelten, muss man andersherum taggen. (Sorry, ich kann gerade nicht in die .osm Datei schauen, ich hoffe es war so gemeint.) Gruss, Chaos PS: Ja, von allen Mappern wird das nicht verstanden. Keine Frage. Wer nur POIs mapped oder gerade noch einen Waldweg mapped, ist damit überfordert. Diese mapper kann man wirklich nur mit einer DAU-gerechten GUI ins Boot holen. Für den auch nur etwas erfahreneren Mapper (der z.B. schon Relationen kennt) ist es denke ich schnell zu durchschauen und anzuwenden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Hallo Ronnie, Am Mittwoch, 19. September 2012, 11:51:45 schrieb Ronnie Soak: Okay, folgendes Beispiel (vereinfachtes Beispiel aus der Wirklichkeit): eine Autobahnbrücke, auf der bei Nässe langsam (80) gefahren werden muss, die Geschwindigkeit wird vor der Brücke schrittweise reduziert: http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm Weil in der Nähe der Autobahn Häuser sind, wird nun beschlossen, von 22:00 Uhr bis 06:00 Uhr eine Geschwindigkeitsbeschränkung von 100 auf dem gesamten Autobahnabschnitt einzuführen. Bitte taggen! auf den Stücken vor und hinter der Brücke: maxspeed:conditional = 100 @ (22:00 - 06:00) Auf den bei Nässe reduzierten Stücken: maxspeed:conditional = 100 @ (22:00 - 06:00); 80 @ (wet) Die detailiertere Bedingung wird jeweils hinten angehägt. Es gilt bei Nässe nach 22Uhr als 80. Soll stattdessen 100 gelten, muss man andersherum taggen. (Sorry, ich kann gerade nicht in die .osm Datei schauen, ich hoffe es war so gemeint.) Die .osm-Datei ist deutlich ausführlicher, in dem Beispiel geht es wirklich darum, das Tagging zu *erleben*. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Am 19.09.2012 11:41, schrieb Eckhart Wörner: Hallo aighes, Am Mittwoch, 19. September 2012, 11:28:37 schrieb aighes: Der GUI ist es doch letztlich nahezu egal, was sie in die Tags schreibt und dem Auswerter ist es auch nahezu egal, was in dem Tag steht (es gibt ein paar Einschränkungen, wie konstante Keys). Egal wie simpel das Schema sein wird, es wird für die meisten Mapper zu kompliziert sein, als das sie es von Hand eintippen. Das halte ich jetzt für eine nicht ganz zutreffende Verallgemeinerung. Ich glaube nicht, dass maxspeed:wet=80 zu kompliziert ist, um von Hand eingegeben zu werden. Es wird eher so sein, dass eine GUI das letzte ist, was kommt. Das war nicht speziell zu diesem Fall gemeint. Es ist eher allgemein so, dass ein Großteil der Mapper primär sich die Tags über die Presets zusammen klickt. Das manuelle Eintragen machen egtl. nur noch die Spezialisten/Pro's, die Sachen eintragen, die ungewöhnlich sind oder es einfach aus vergangen Zeiten gewohnt sind. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Hi Eckhart, aighes auf den Stücken vor und hinter der Brücke: maxspeed:conditional = 100 @ (22:00 - 06:00) Auf den bei Nässe reduzierten Stücken: maxspeed:conditional = 100 @ (22:00 - 06:00); 80 @ (wet) Die detailiertere Bedingung wird jeweils hinten angehägt. Es gilt bei Nässe nach 22Uhr als 80. Soll stattdessen 100 gelten, muss man andersherum taggen. (Sorry, ich kann gerade nicht in die .osm Datei schauen, ich hoffe es war so gemeint.) Die .osm-Datei ist deutlich ausführlicher, in dem Beispiel geht es wirklich darum, das Tagging zu *erleben*. Ok, dann mach ich mich da heute abend noch mal dran. Das halte ich jetzt für eine nicht ganz zutreffende Verallgemeinerung. Ich glaube nicht, dass maxspeed:wet=80 zu kompliziert ist, um von Hand eingegeben zu werden. Es wird eher so sein, dass eine GUI das letzte ist, was kommt. Das war nicht speziell zu diesem Fall gemeint. Es ist eher allgemein so, dass ein Großteil der Mapper primär sich die Tags über die Presets zusammen klickt. Das manuelle Eintragen machen egtl. nur noch die Spezialisten/Pro's, die Sachen eintragen, die ungewöhnlich sind oder es einfach aus vergangen Zeiten gewohnt sind. Ich fühle mich gerade alt. Also ich benutze zum Beispiel nahezu immer manualle keys/values und die Vorlagen bestenfalls als ersten Vorschlag zum Tagging. Schon weil ich eine Vielzahl von Editoren benutze und die Vorlagen meist nicht einheitlich (oder nicht vorhanden) sind. Aber ich bin auch nicht die breite Mehrheit. Zugegeben. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPS Anfänger
Hallo, ich arbeite jetzt ein paar Wochen an der Verbesserung der OSM Daten in meiner Gegend. Jetzt plane ich mir ein GPS Gerät zuzulegen um selber noch genauere Daten zu holen. Da ich noch keine Erfahrung damit habe bin ich mir nicht sicher ob ich mir ein Gerät wie z.B. Garmin eTrex oder Dakota, die ja auch zwischen 100 und 600 Euro kosten, oder ich lege mir eine Apple iPhone zu das ich mit einer geeigneten App ausstatte und gleichzeitig noch mehr davon habe. Jetzt weis ich natürlich nicht wie die Apps auf einem iPhone mit OSM funktionieren, oder wie gut die Auflösung des GPS im iPhone ist. Oder evtl funktioniert das mit einem iPhone überhaupt nicht richtig, weil?? Ich hab damit noch keine Erfahrung. Mein Ziel ist es Strecken und Punkte (Postkasten, Kreuzungrn, Brücken) mit dem Fahrrad abzufahren und die Punkte aufzuzeichnen. Diese Trackingdaten dann in JOSM zu übernehmen und bestehende Punkte anzupassen oder neu einzutragen. Zu was würdet Ihr mir Raten und wovon soll ich die Finger lassen? Besten Dank für Eure Hilfe Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Quo Vadis FOSSGIS 2013
Am 19. September 2012 02:16 schrieb Tirkon tirko...@yahoo.de: Georg Lösel georg.loe...@fossgis.de wrote: Ein weiteres Projekt, das derzeit von der Wikimedia gefördert wird, sind Luftaufnahmen, um Wikipedia Artikel besser illustrieren zu können. Hier könnte man abklären, inwiefern so etwas auch für OSM nützlich sein kann. Man könnte dies mit einem Gedanken weiterspinnen, der sich zugegebenermaßen zunächst verwegen anhört: einen eigenen OSM Satelliten im Weltall. hehe, das hört sich im ersten Moment vielleicht interessant an, aber mit wesentlich geringerem (finanziellem und technischem) Aufwand kann man m.E. wesentlich mehr rausholen, wenn man aus geringerer Entfernung fotographiert, z.B. mit Dronen, Ballons, Drachen oder Flugzeugen. AFAIK sind die Luftbilder, die man bei Bing, Aerowest, Google und anderen bestaunen kann, von Flugzeugen aus aufgenommen und nicht von Satelliten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Anfänger
On 09/19/2012 01:12 PM, wwl wrote: Zu was würdet Ihr mir Raten und wovon soll ich die Finger lassen? Vorteile echter GPS Geräte: (hoffentlich) besserer Empfang und genauere Ergebnisse, und vor allem längere Batterielebensdauer als ein typisches Smartphone, optional barometrische Höhenmessung statt GPS (in der Höhe systembedingt sehr ungenau), geländetaugliches Gehäuse Vorteile eines Smartphone: OSM-Erfassungsanwendungen, Möglichkeit OSM Kacheln direkt anzeigen zu lassen, evtl. direkter Upload von GPX Tracks zu OSM, integrierte Kamera für Details vor Ort ... Ich besitze beides (Garmin eTrex Vista und Smartphone/Tablet), nehme aber mittlerweile idR nur noch das Telefon oder Tab mit, wobei ich das Telefon mit einem deutlich größeren Akku ausgestattet habe und auch nach ca. sechs Stunden mit aktivem GPS, vielen Fotos und ca. 30% der Zeit aktivem Display noch mit fast 40% Restladung nach hause komme. Konkret ist das bei mir ein Samsung Galaxy Nexus mit 3500mAh Akku, das macht das Gerät zwar etwas dicker und schwerer, IMHO aber auch handlicher, und leichter als ein Garmin ist es immer noch allemal. Ich weiß nicht wie die App-Situation auf dem iPhone aussieht, auf Android-Seite bin ich mit dem Angebot (insb. OsmTracker für Android) glücklich (und auch damit das ich selbst entscheiden darf ob mir der interne Akku reicht oder ob ich ihn lieber durch einen größeren ersetze) Weiterer Android-Vorteil für mich ist das ich zB an OsmTracker mitentwickeln könnte ohne auch noch einen großen Mac besitzen zu müssen (hab sogar ein PowerBook, aber iPhone SDK gibts nur für Intel CPUs, ältere PowerPC Apples stehen da im Regen), aber das ist eine andere Geschichte -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Anfänger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-09-19 13:12, wwl wrote: Hallo, ich arbeite jetzt ein paar Wochen an der Verbesserung der OSM Daten in meiner Gegend. Jetzt plane ich mir ein GPS Gerät zuzulegen um selber noch genauere Daten zu holen. Da ich noch keine Erfahrung damit habe bin ich mir nicht sicher ob ich mir ein Gerät wie z.B. Garmin eTrex oder Dakota, die ja auch zwischen 100 und 600 Euro kosten, oder ich lege mir eine Apple iPhone zu das ich mit einer geeigneten App ausstatte und gleichzeitig noch mehr davon habe. Jetzt weis ich natürlich nicht wie die Apps auf einem iPhone mit OSM funktionieren, oder wie gut die Auflösung des GPS im iPhone ist. Oder evtl funktioniert das mit einem iPhone überhaupt nicht richtig, weil?? Ich hab damit noch keine Erfahrung. Mein Ziel ist es Strecken und Punkte (Postkasten, Kreuzungrn, Brücken) mit dem Fahrrad abzufahren und die Punkte aufzuzeichnen. Diese Trackingdaten dann in JOSM zu übernehmen und bestehende Punkte anzupassen oder neu einzutragen. Zu was würdet Ihr mir Raten und wovon soll ich die Finger lassen? Grob gesagt: iPhone/Android/... sind +/- 10-50 Meter genau. Die Garmin Geräte sind meistens erheblich genauer. Allerdings sind die Garmin Geräte eher auch Multi-Funktions Geräte, die neben GPS Logs auch Karten anzeigen und andere Dinge machen. Wenn man wirklich brauchbare GPS Tracks günstig haben möchte, sind GPS Logger die bessere Wahl. Aber auch da gilt: den Weg entsprechend oft abgehen/fahren und mitteln. Hinweis: wenn man POI (explizite Punkte) eintragen will, sind GPS Logger aber ungeeignet. Hinweis 2: ggf. ist es aber auch ausreichend, von Bing Bildern abzuzeichnen, wenn man vorher den Versatz korrekt ermittelt, also 3 Referenzpunkte nehmen und Bild hin und her schieben. Somit mein Tip: 1. GPS Logger 2. Garmin/anderes Gerät 3. iPhone/Android Es mag aber auch andere Android Geräte geben, die eine ähnliche gute Genauigkeit wie die Garmin Geräte geben, ich pers. kenne leider keine jetzt aus dem Kopf. Klar, die Android/iOS Geräte haben einen gewissen Mehrwert. Den man aber bei den meisten Geräten damit erkauft, das man Tracks ggf. x-mal mehr ablaufen muß, um einen brauchbaren Track zu bekommen, also bessere Mittelwerte erlangen. Besten Dank für Eure Hilfe Christian MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBZr7kACgkQmWhuE0qbFyOZcQCeLk+I3JyKUQL4gu2V/IPAAJgA JeEAn27FvGHQvIF+6UxEaKE0aPJOBi8/ =/0jR -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Einträge, vorlage JOSM, roof Tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-09-19 11:24, Peter Barth wrote: Hallo, Lars Schimmer schrieb: Der building:parts=* sollte ja nur die Hülle des gesamten Gebäudes umfassen, um zu sagen: das ist ein Gebäude, welches horitzontal/vertikal in kleinere Teilstücke aufgeteilt werden soll. Die einzelnen Teilstücke sind dann mit building:part=yes gekennzeichnet. nein, die Hülle ist immer building=*. Hm, ok. Ich hab halt ein Proposal mit reingemixt: http://wiki.openstreetmap.org/wiki/Proposed_features/building:parts Aber ich sehe schon, building=yes sollte noch mit dran, bzw. building=*, je nach dem, was es ist. Löst auch eines der kleinen Widersprüche, die ich hatte (building=school z.B. sollte dann an die Outline). Zugegeben, das ist auf der Simple_3D_Buildings-Seite nicht sauber beschrieben aber deine Interpretation les ich da erst Recht nicht raus. Wer suchet, der findet alles, was einem gefällt ;-) Nicht umsonst frag ich hier nach und hole mit Ratschläge ein. Das ist auch im Sinne der Abwärtskompatibilität sinnvoll: Auch wenn ein Gebäude aus mehreren building:part=yes besteht hat man trotzdem noch die herkömmliche building=* Hülle. Schon klar. Seh ich ja an dem einen Gebäude, das ich gestern bearbeitet hatte und plötzlich ned mehr in Mapnik aufscheint... Nu ist auch klar, warum. Gruß, Peda MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBZsssACgkQmWhuE0qbFyNGhQCghokmJnAxXOUreqNnFZ8Zz+1E JzYAmwWilJNoVwx0EsiINd2NLZjrMK7F =UFJD -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Anfänger
Hallo Christian, Original-Nachricht Betreff: [Talk-de] GPS Anfänger Datum: Wed Sep 19 2012 13:12:05 GMT+0200 Von: wwl use...@schani.com An: talk-de@openstreetmap.org ich arbeite jetzt ein paar Wochen an der Verbesserung der OSM Daten in meiner Gegend. Jetzt plane ich mir ein GPS Gerät zuzulegen um selber noch genauere Daten zu holen. Da ich noch keine Erfahrung damit habe bin ich mir nicht sicher ob ich mir ein Gerät wie z.B. Garmin eTrex oder Dakota, die ja auch zwischen 100 und 600 Euro kosten, oder ich lege mir eine Apple iPhone zu das ich mit einer geeigneten App ausstatte und gleichzeitig noch mehr davon habe. Jetzt weis ich natürlich nicht wie die Apps auf einem iPhone mit OSM funktionieren, oder wie gut die Auflösung des GPS im iPhone ist. Oder evtl funktioniert das mit einem iPhone überhaupt nicht richtig, weil?? Zu Apps kann ich leider nichts sagen. Ich nutze ein Garmin Oregon und bin damit - vorallem, was die GPS-Genauigkeit angeht, ziemlich zufrieden. Ein reines GPS-Gerät liefert Dir gegenüber einem Smartphone mit GPS-Empfänger zumindest einen - für mich sehr entscheidenen - Vorteil: Du kannst die Akkus wechseln. Mit aktivem GPS hält ein SmartPhone je nach Modell etwa 4 Stunden durch. Ist der Akku leer, dann kannst Du nicht weiter aufzeichnen. Bei einem GPS-Gerät wechselst Du einfach die Mignon-Akkus aus. Ich hab damit noch keine Erfahrung. Mein Ziel ist es Strecken und Punkte (Postkasten, Kreuzungrn, Brücken) mit dem Fahrrad abzufahren und die Punkte aufzuzeichnen. Diese Trackingdaten dann in JOSM zu übernehmen und bestehende Punkte anzupassen oder neu einzutragen. Es gibt zwei Dinge, die Du aufzeichnen kannst. Zum einen Deine mit dem Gerät zurückgelegte Wegstrecke (= GPS-Track) und einzelnen Wegpunkte, die Du aktiv anlegst. Am Ende wirst Du bei jedem Endgerät eine oder mehrere gpx-Dateien mit den aufgezeichneten Daten erhalten. Die Aufzeichnung von speziellen Punkten (den POI, also Briefkasten etc) ist mit z.B. mit dem Oregon etwas nervig. Das geht mit speziellen Apps oftmals besser, weil diese teilweise vorgefertigte Schaltflächen haben. Zu was würdet Ihr mir Raten und wovon soll ich die Finger lassen? Das hängt auch etwas davon ab, was Du sonst noch mit dem Gerät anfangen würdest und wie Dein geplantes Mapping-Verhalten aussieht. Wenn Du nur hin und wieder ein paar Punkte aufzeichnen willst, ist vermutlich ein SmartPhone, mit dem Du noch mehr anfangen kannst, die bessere Variante. Bist Du sowieso viel wandernd unterwegs und zeichnest auch lange Tracks auf, würde ich Dir eher zu einem GPS-Gerät raten. Dann kommt es darauf wieder auf andere Faktoren an; z.B. ist Dir ein großes Display wichtig, damit Du einen möglichst großen Kartenausschnitt siehst... Viele Grüße, Constanze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
