Re: [talk-ph] Update to Openstreetmap.org.ph
Nice buttons! I'll add them up to some of my websites/blogs. As for the blog, I'd volunteer but I'm already hard-pressed to write for my own blogs that I'm not sure at this point in time if I can commit to writing for yet another blog. Well, I could probably cross-post all of the OSM-related blog posts that I write on my main blog to this proposed OSM.org.ph blog if that's ok. On Sat, Jan 24, 2009 at 3:18 AM, Ahmed Farooq ah...@enthropia.com wrote: http://www.openstreetmap.org.ph/ - we've now included some ready-made buttons to use for the website. Wanted to know if there are volunteers to help post/run a blog? It would be most useful as a public face. -A -Original Message- From: talk-ph-boun...@openstreetmap.org [mailto:talk-ph-boun...@openstreetmap.org] On Behalf Of Jim Morgan Sent: Tuesday, January 20, 2009 9:11 PM To: OSM Subject: Re: [talk-ph] OSM Philippines meet-up maning sambale wrote, On Thursday, January 15, 2009 04:00 PM: Is Feb 7 or 8 OK with everyone? Post your availability and preferred venue here. Saturday 7th is good. Would prefer Makati, but Ortigas is also possible. Or also possibly somewhere like the harbour side at Mall of Asia, or Harbour View near CCP. Maybe about 6pm ish for a sundowner? If we do an early evening meet, then it leaves us free to go about our normal Saturday evening engagements. Jim ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[OSM-legal-talk] 23rd Dec board meeting
Comments on the minutes of the 23rd Dec board meeting It is good that the minutes are now posted. I was however disappointed to get them the day of the next meeting and a month after the meeting in question. It is good to see that the November minutes have been approved. Sub-working groups and communications It is very useful to start seeing brief biographies of the directors appearing on the website (http://foundation.openstreetmap.org/officers-board/board-member-bios/ ). Does Nick Black have a 'substantial' shareholding in CloudMade? If so I think this should be noted, otherwise 'none' would be clearer than no entry. Also for consistency with other entries Nick's entry should list 'other directorships' not 'directorships'; there is no need to repeat the OSM Foundation directorship. Steve Coast's entry is very thin. I suggest that it should contain the same level of details as the other - I note that the board minutes indicate that they are still waiting for content from him. Mikel gives a link to his blog. This might be an appropriate addition for the other entries to allow people to quickly understand where people are coming from. Can I say that we have a great board - I love the diversity, it should give the foundation a very strong base. Workshops I am pleased that the planning meeting is going ahead and that it will be a full weekend. I am less pleased that the dates were chosen by the board without checking with others (including ITO) who they know are keen to attend, especially as the dates clash with a holiday booked by one of our key people months ago! ITO has made a big investment in OSM development and does expect to be included in and does wish to attend. Were GeoFabric consulted on the dates, I hope so? Can they make it? I hope so. What about other people? Can Richard Fairhurst - author of PotLatch - make those dates? I believe Sundays were not possible for him. Can CloudMade people make it? I guess so since their two main people were in on the decision;) I see this as one of many examples of benefits that CloudMade give themselves by driving the process. Please can some other dates be proposed? I will again suggest that we put up a wiki page where people can sign up, give the dates that they can make, and then we decide a group which date works best. I have also had a request from a non-english native speaker that the attendance should be limited to people who are actively involved in development to keep the numbers down. This is an important strategic technical meeting and as such I think that it is a reasonable request and will make it easier for people for whom English is not a first language to contribute. It suggest that it should not also become a 'local-meetup' for anyone who is interested and lives locally to come along. TradeMarks and Domains I note that the transfer of the trademarks has still not happened (I checked at the IPO last night). The minutes seem to confuse the process of transferring the application with the process of progressing the applications themselves. I have already provided the following information to the board but will post it here for the record. Possible Grant, Andy or Steve could get the form downloaded, filled out, signed and in the post today - it only takes a few minutes. Here is the advice from our lawyer: The transfer should be straight forward and simple to complete. In case of any doubt, you may wish to let Grant Slater know that the relevant form is TM16 (which can be obtained from the IPO website at www.ipo.gov.uk ). The simple details need to be completed and the form signed by Steve Coast and also on behalf of the OSMF. The TM16 should then be returned by post to the IPO (the address is on the form), together with a £50 fee. I am pleased to see that the other OSM related domains have been transfered to the foundation. OSM Open Data License There are many comments already on legal-talk that I won't repeat here. I do however note from the minutes that all communications with Jordan had broken down. Also that No hosting option for the licence is currently available and therefore OSMF may need to host. These seems to indicate that there is a lot more work to be done. I note that Steve [is] reluctant to publish publicly as it would invite another round of changes ... Henk asked about getting support from major contributors. Nick and Andy felt it was against the spirit of the project to treat some contributors as having special status. Umm, so Steve Coast (director and shareholder in Cloudmade) and Nick Black (director and probably also a shareholder in Cloudmade) and Andy Robinson (paid contractor to CloudMade) think that no one else should be able to comment on the license, notable Peter Miller (director and shareholder in ITO) and Frederic Ramm (director and shareholder in Geofabric) who have asked
Re: [OSM-legal-talk] 23rd Dec board meeting
Peter Miller wrote:
Is there not a large potential conflict of interest between SteveC in relation
to his driving this change within the Foundation and also being a director of
a company that could well benefit from the OSM project not offering a full set
of services? I don't know, but I certainly don't have the information to feel
comfortable with this initiative until we have some more facts available to
us.
I think this is uncalled for.
There are any number of technical things you need to think through before
switching from a system that pretty much works to something (anything) else.
While it's valid to question what those things are, and their significance,
I don't think you can jump from that to it all being an evil plot hatched in
CM's volcano lair.
You argue that anyone with a commercial interest in OSM (e.g., me) who's
listed on the {{PD-user}} page (me again) has a potential conflict of
interest.
You could argue that as a commercial interest who's been pushing very hard
for the licence issue to be resolved, perhaps you have some ulterior motive
too...
Nothing useful comes out of that kind of discussion.
The current progress on the licence is certainly frustrating for those of us
who are thinking about how our companies can best use and contribute to OSM,
but I suspect it's been a very frustrating process on the OSMF side as well.
E.g., we have no idea what the background to all communications with Jordan
had broken down was, or what impact that has had. It would be nice to know
what happened, but having a public discussion about that while trying to
resolve whatever the issue was probably wouldn't have been helpful.
I would definitely recommend you stand for the OSMF next year, as I think
you could make a valuable contribution to the process (e.g., I agree with
your thinking re the trademark).
I don't know if you'll find the grass is any greener though.
Although the licence project seems to be moving forward very slowly, it is
at least moving (vs what happened previously, where we had endless
GPS-vs-BSD debates on the mailing list but no real progress whatsoever).
-dair
___
d...@refnum.com http://www.refnum.com/
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Licensing Working Group report, 2009/01/22
On 24 Jan 2009, at 15:27, Rob Myers wrote: Peter Miller wrote: Without a public vote the board are effectively saying to each and every one of use individually: 'accept these new terms or please leave the community now and don't slam the door - oh, and we will remove your data shortly'. Clearly this approach will result in lots of people slamming doors! I cannot imagine people leaving if they agree with the licence, and I cannot imagine people who disagree with the licence staying whether it is announced or voted on. Doors will slam either way. There would be no evidence that the majority of the community agreed with the new license, Unless the majority relicence. There is huge difference between the majority being ask one by one to 'relicense or leave now', and one where we are asked if we support it and then later being asked to accept the majority verdict (which is very likely to be in favour of re-licensing). and there were always be accusations of foul play from the inevitable splinter groups. There will anyway. Quite, which is why due process needs to be seen to be done, then we can just shrug and mutter about not being able to please all the people all the time. Currently people will have a very legitimate reason to complain. To be clear, this must be a 'whole community' vote, not a vote by board members, or even just by foundation members. How will the community be defined and how will irregularities and fraud be avoided? Only contributors to OSM can vote. The vote must be made through the OSM messaging system. One person one vote. And how will a silent majority who don't care about licencing not be represented as a vote against the new licence? Only people who vote will be counted. We must recognise that most people will not be interested and will follow the crowd. I suggest a threshold is set for acceptance as it stands. If that threshold is not met then it isn't necessarily back to square one - it might be possible to come back again with a revised version that meets the concerns, but the clear aim is to get it adopted in one go. I don't think a vote is necessarily a good thing. I do think public review is a good thing, however fed up everyone may be. I am glad you agree on a public review. However given that there will still be vocal opposition even after any number of reviews then how do you propose to gauge the actual level of the opposition and if the new license should be adopted? We can assume that one or two people will make a huge amount of noise on the list and give the impression that there is a lot of opposition when this might not actually be the case. I suggest that a decision made on the basis of a vote if preferable to one made on the basis of who shouts loudest and is also better than one made 'be decree' (which is what I think is being considered at present). Thanks Peter - Rob. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] 23rd Dec board meeting
On 24 Jan 2009, at 13:11, Dair Grant wrote:
Peter Miller wrote:
Is there not a large potential conflict of interest between SteveC
in relation
to his driving this change within the Foundation and also being a
director of
a company that could well benefit from the OSM project not offering
a full set
of services? I don't know, but I certainly don't have the
information to feel
comfortable with this initiative until we have some more facts
available to
us.
I think this is uncalled for.
To be clear, all I am saying is that Steve has two different roles and
that there may be different outcomes preferred in these different
roles, that is my understanding of the phrase 'conflicted', not that
the person has indeed exploited the situation (or as you suggest below
is 'evil'!). I can assure you Steve is not that!
I do note that the following definition of the phrase 'conflict of
interest' does seem to imply that there should indeed be evidence of
an inappropriate decision for the phrase to be used. If so then I am
wrong to use it and I apologise for any confusion given.
http://legal-dictionary.thefreedictionary.com/Conflict+of+Interest
According to the above definition I should have said that there is
only the 'appearance of a conflict of interest' in this case. To quote:
The appearance of a conflict of interest is present if there is a
potential for the personal interests of an individual to clash with
fiduciary duties, such as when a client has his or her attorney
commence an action against a company in which the attorney is the
majority stockholder.
There are any number of technical things you need to think through
before
switching from a system that pretty much works to something
(anything) else.
While it's valid to question what those things are, and their
significance,
I don't think you can jump from that to it all being an evil plot
hatched in
CM's volcano lair.
I hope the above clarification is enough to show that I am not at all
suggesting on 'evil plot', only that Steve has two distinct interests.
You argue that anyone with a commercial interest in OSM (e.g., me)
who's
listed on the {{PD-user}} page (me again) has a potential conflict of
interest.
No, you only have one interest, which is that you are a user of the
data and are advocating your position. You are not also the judge and
jury who is deciding the case or indeed the whole process.
You could argue that as a commercial interest who's been pushing
very hard
for the licence issue to be resolved, perhaps you have some ulterior
motive
too...
I don't have a conflict of interest, I have one interest, which is
that we have a good resolution of this quickly that works for my
company. I agree I am pushing for it, but again, I am also not
deciding which way we jump or on the process.
Nothing useful comes out of that kind of discussion.
Agreed.
The current progress on the licence is certainly frustrating for
those of us
who are thinking about how our companies can best use and contribute
to OSM,
but I suspect it's been a very frustrating process on the OSMF side
as well.
Agreed. I am only suggesting for an improved process which should
reduce frustration on all sides. I am guessing (only guessing) that
SteveC has decided to make this decision 'by decree' because he knows
it is better than repeating a load of futile arguments on legal-talk
where everyone gets cross. My point it that making the decision by
decree has its own serious shortcomings and that we should establish a
better way.
E.g., we have no idea what the background to all communications
with Jordan
had broken down was, or what impact that has had. It would be nice
to know
what happened, but having a public discussion about that while
trying to
resolve whatever the issue was probably wouldn't have been helpful.
Its a tough call and it may be appropriate to keep that discussion
'behind closed doors' but that is not a reason to shut out the whole
community out of the whole process.
I would definitely recommend you stand for the OSMF next year, as I
think
you could make a valuable contribution to the process (e.g., I agree
with
your thinking re the trademark).
I don't know if you'll find the grass is any greener though.
Agreed, however I would probably be more effective helping from the
outside in any number of ways. I believe I am better qualified to
contribute to particular working groups as required than to be on the
board itself. The concept of working groups seems to be emerging at
the moment within the foundation which is a very good sign, but the
process of deciding who is on the working groups currently seems a bit
arbitrary.
Although the licence project seems to be moving forward very slowly,
it is
at least moving (vs what happened previously, where we had endless
GPS-vs-BSD debates on the mailing
Re: [OSM-legal-talk] 23rd Dec board meeting
On Sun, 25 Jan 2009, Dair Grant wrote:
You argue that anyone with a commercial interest in OSM (e.g., me) who's
listed on the {{PD-user}} page (me again) has a potential conflict of
interest.
That's the way Australian law works.
If I am on a Board (which I am) and some other aspect of my life, even
non-commercial could affect my decision making I have to declare the
interest.
Liz
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] 23rd Dec board meeting
Liz wrote:
On Sun, 25 Jan 2009, Dair Grant wrote:
You argue that anyone with a commercial interest in OSM (e.g., me) who's
listed on the {{PD-user}} page (me again) has a potential conflict of
interest.
That's the way Australian law works.
If I am on a Board (which I am) and some other aspect of my life, even
non-commercial could affect my decision making I have to declare the
interest.
OSMF Board member bios, declaring other interests.
http://foundation.openstreetmap.org/officers-board/board-member-bios/
Regards
Grant
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] 23rd Dec board meeting
On 24 Jan 2009, at 20:26, Grant Slater wrote:
Liz wrote:
On Sun, 25 Jan 2009, Dair Grant wrote:
You argue that anyone with a commercial interest in OSM (e.g., me)
who's
listed on the {{PD-user}} page (me again) has a potential conflict
of
interest.
That's the way Australian law works.
If I am on a Board (which I am) and some other aspect of my life,
even
non-commercial could affect my decision making I have to declare the
interest.
OSMF Board member bios, declaring other interests.
http://foundation.openstreetmap.org/officers-board/board-member-bios/
It is not sufficient to just declare ones interest. The following is
the verbatim response to the question when we asked for clarification
from our lawyer. It seems that the board can vote to allow a
'conflict' however it also seems sensible to avoid such a tricky
situation where possible. I am particularly concerned where two
directors both with the apparent conflicts dismiss the concerns of
another directors (ie those of Henk when he suggested more
consultation was appropriate and Steve/Nick disagreed).
the position under the Companies Act 2006 is that a director has a
duty to avoid a conflict of interest. However the conflict can be
authorised by the Board (section 175, the Act).
Authorisation of conflict requires the Board to vote to permit the
conflict, such vote to be undertaken by the remaining directors. For
the purposes of this vote the interested director (and any other
interested director) cannot be be counted towards either the quorum of
the Board meeting or the vote.
Directors also have a duty to declare all interests (including the
nature and extent of such interest) which they have in any proposed
transaction or arrangement to be entered into by the company. Further
declarations must be made as the scope on nature of such interest
changes (section 177, the Act).
A director also has a duty not to accept benefits from third parties
which are conferred by reason of his being a director or doing (or not
doing) anything as a director. This duty will only be triggered if the
acceptance of the benefit is likely to give rise to a conflict of
interest and/or duties (section176, the Act).
Depending upon the precise circumstances this duty not to accept
benefits could be relevant in the case of the Foundation. Presumably
Steve Coast Will receive some form of benefit from his other company
which could be argued to arise as a result of actions which he
undertakes as a director of the Foundation.
Regards,
Peter
Regards
Grant
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] 26 languages
Ten days ago, I wrote: Wikipedia's article about OpenStreetMap is now available in 26 languages. The most recently added is a brief translation in Swahili, the East African language. After Portuguese and Afrikaans have been added, there are now 28 languages. But of the largest Wikipedia languages, we're still missing Japanese (5th biggest) and Chinese (12th). Who can help with this? English, http://en.wikipedia.org/wiki/OpenStreetMap Japanese, http://ja.wikipedia.org/wiki/OpenStreetMap Chinese, http://zh.wikipedia.org/wiki/OpenStreetMap Next in Wikipedia size without an OpenStreetMap article are Catalan (Wikipedia's 15th largest language), Volapük (19), Indonesian (25), Hebrew (26), Korean (27), Vietnamese (30), Serbian (31), Bulgarian (33), and Persian (35). For comparison, Swahili is the 89th largest language of Wikipedia, having 8400 articles, http://meta.wikimedia.org/wiki/List_of_Wikipedias Careful! Of course you will have to follow the rules of Wikipedia and prove why this article is needed, relevant, sourced, etc. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - Relation:type=route_instruction
Hi, Just a quick mail to announce that the following proposal is now in the RFC stage, comments are of course welcome! http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Droute_instruction Yann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-legal-talk] Open Data Licence (Re: 23rd Dec board meeting)
On Sat, Jan 24, 2009 at 11:30:19AM +, Peter Miller wrote: OSM Open Data License There are many comments already on legal-talk that I won't repeat here. I do however note from the minutes that all communications with Jordan had broken down. Also that No hosting option for the licence is currently available and therefore OSMF may need to host. These seems to indicate that there is a lot more work to be done. I note that Steve [is] reluctant to publish publicly as it would invite another round of changes ... Henk asked about getting support from major contributors. Nick and Andy felt it was against the spirit of the project to treat some contributors as having special status. I can’t help but think it would be more with the spirit of the project to have open development of the licence, and that it would have been beneficial if this had been an open development much earlier. By having a closed development process, and publishing drafts for review, OSMF have forced the process to involve rounds of consultation. Had development been open, it would have benefitted from continual input from the community. The same input that we have been trying to provide with the development of use cases, wiki pages about the licence and how it should work, without even knowing what the current state of the licence is. Allowing all contributors to provide input on the development is also a fair way to avoid some having special status. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] osmrender.pl version 2 published
hi, although the program will probably never be finished I published version 2. please adapt to your needs! version 2 creates - SVG files - street names example here: http://www.gary68.de/osm/hof.svg have fun downloads http://wiki.openstreetmap.org/wiki/User:Gary68 dokumentation here http://wiki.openstreetmap.org/wiki/Osmrender.pl http://wiki.openstreetmap.org/wiki/Osmgraph.pm gerhard gary68 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] uStream .tv broadcast 2pm PST 5pm EST - geobase import
Hi all, if you happen to be around at 2pm PST i'll be hosting a show on uStream.tv Todays topic is about the GeoBase NID, we had some discussion on the talk-ca list, so its worth reviewing. (i cc'd to main talk list, as ideas are welcome from everywhere) In light of France getting the OK for post codes; Canada might also, so there needs to be a way to accomidate it. We should be able to update the geobase import talk page post the unanswered questions. If the feedback is good, i'll plan another broadcast with a few weeks notice. Same channel as last time search 'across canada trails' Cheers, Sam Vekemans Across Canada Trails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 26 languages
Next in Wikipedia size without an OpenStreetMap article are Catalan... And here it is!! http://ca.wikipedia.org/wiki/OpenStreetMap Regards, Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] uStream .tv broadcast 2pm PST 5pm EST - geobase import
2009/1/24 Sam Vekemans acrosscanadatra...@gmail.com: In light of France getting the OK for post codes; Canada might also, so there needs to be a way to accomidate it. We should be able to update the geobase import talk page post the unanswered questions. I thought it was Iceland with the postcodes, but France with the official land registry maps, or something similar... -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] uStream .tv broadcast 2pm PST 5pm EST - geobase import
I dunno about Iceland, but you're right about France, it is the official land registry map that we got access to. Yann Le 24 janv. 09 à 23:30, Thomas Wood a écrit : 2009/1/24 Sam Vekemans acrosscanadatra...@gmail.com: In light of France getting the OK for post codes; Canada might also, so there needs to be a way to accomidate it. We should be able to update the geobase import talk page post the unanswered questions. I thought it was Iceland with the postcodes, but France with the official land registry maps, or something similar... -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] mapping driveways
Sorry if this is on the wiki - I've tried to read the relevant parts. I live in a semi-rural area where there are a lot of long driveways. Some of these show up on the map, mostly due to MassGIS bulk imports. For commercial places, and other places where the public might go, I've set a few to these to service. An example is the access road to Minuteman Airfield in Stow, MA, USA: http://www.openstreetmap.org/?lat=42.46068lon=-71.51526zoom=17layers=0B00FTF But there are some that seem to be just some person's house, probably in the databsae because it showed up on the aerial photo, and some that just seem a bit goofy. An example is the unnamed way going SSE from Crescent St.: http://www.openstreetmap.org/?lat=42.43777lon=-71.5016zoom=17layers=0B00FTF Should I just remove these ways? They seem like clutter and not useful. The USGS topo maps show very thin lines for driveways, so it's clear they aren't real roads. Calling them service doesn't seem right. So my real question boils down to: when there is an area perhaps 100m long and 3m wide paved to get to a single house, should that be represented, and how? How do we do this so it's clearly rendered differently than a proper road. pgpBAuOMd6aTD.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapping driveways
Greg Troxel schrieb: Sorry if this is on the wiki - I've tried to read the relevant parts. I live in a semi-rural area where there are a lot of long driveways. Some of these show up on the map, mostly due to MassGIS bulk imports. For commercial places, and other places where the public might go, I've set a few to these to service. An example is the access road to Minuteman Airfield in Stow, MA, USA: http://www.openstreetmap.org/?lat=42.46068lon=-71.51526zoom=17layers=0B00FTF But there are some that seem to be just some person's house, probably in the databsae because it showed up on the aerial photo, and some that just seem a bit goofy. An example is the unnamed way going SSE from Crescent St.: http://www.openstreetmap.org/?lat=42.43777lon=-71.5016zoom=17layers=0B00FTF Should I just remove these ways? They seem like clutter and not useful. The USGS topo maps show very thin lines for driveways, so it's clear they aren't real roads. Calling them service doesn't seem right. So my real question boils down to: when there is an area perhaps 100m long and 3m wide paved to get to a single house, should that be represented, and how? How do we do this so it's clearly rendered differently than a proper road. First of all, you should NEVER remove anything from the database, unless you have made certain by your own eye that the object in question is an error and not existing in reality! Even than take care not to remove anything marked as abandoned or alike, that marks this object was once here and the info is kept for historical reasons. Here in germany we are simply not asking if something should be included! People in densely mapped areas are starting to map single trees and litter bins - not all of us doing so, but that's not the point here. How this should be tagged depends on what's on the ground. Please have a look at: http://wiki.openstreetmap.org/index.php/Map_Features It indicates to use highway=service together with service=driveway. Funnily enough, I don't have a clear understanding what a driveway actually is, seems to be an american english specific term? Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 26 languages
Hi, Lars Aronsson wrote: After Portuguese and Afrikaans have been added, there are now 28 languages. But of the largest Wikipedia languages, we're still missing Japanese (5th biggest) and Chinese (12th). Why bother educating the Chinese about OSM when they will be jailed trying to contribute? 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] uStream .tv broadcast 2pm PST 5pm EST - geobase import
Thanks, ya your right :) The show went good (IMO) as the question is now more apparent. For government/bulk imports -where we know that updates are available; how is it dealt with? The solution is this IMO: 1- take the latest OSM Data, as a file; the exact size area of the shape file to be imported. 2 - extract only the possable tags (if any) that are showing the same info as you want to have the new data shown as. 3 -convert the OSM to shape file 4 - make a backup of OSM file 5 -remove those same selected osm data OUT OF the osm database. 6 - using whatever postGIS program, look at both shape files, and see just how the 2 match up. 7 add osm tags the the whole thing. 8 use one of the bug finder tools to find duplicate data, and PERGE all the info together. 9 the result is a file that contains; new imported data with osm tags, untouched osm data (that no match was available), and perged data (osm imported) 10 convert the file to OSM and upload to OSM. Please poke fun at the steps, :) cheers, Sam On 1/24/09, Thomas Wood grand.edgemas...@gmail.com wrote: 2009/1/24 Sam Vekemans acrosscanadatra...@gmail.com: In light of France getting the OK for post codes; Canada might also, so there needs to be a way to accomidate it. We should be able to update the geobase import talk page post the unanswered questions. I thought it was Iceland with the postcodes, but France with the official land registry maps, or something similar... -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 26 languages
On 1/24/09, Frederik Ramm frede...@remote.org wrote: Hi, Lars Aronsson wrote: After Portuguese and Afrikaans have been added, there are now 28 languages. But of the largest Wikipedia languages, we're still missing Japanese (5th biggest) and Chinese (12th). Why bother educating the Chinese about OSM when they will be jailed trying to contribute? The answer is simple and obvious, not all Chinese speaking people live in China. I live in Toronto, Ontario, Canada, and some 11% of the population (over 280,000 people) is of Chinese decent, and relevant for the likes of a Wikipedia entry, manages to support three daily Chinese language newspapers... So, for the benefit of oversees Chinese a Wikipedia entry would be a good thing (the more mappers the better in my books). Colin McGregor 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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapping driveways
Ulf Lamping ulf.lamp...@googlemail.com writes: First of all, you should NEVER remove anything from the database, unless you have made certain by your own eye that the object in question is an error and not existing in reality! Even than take care not to remove anything marked as abandoned or alike, that marks this object was once here and the info is kept for historical reasons. Yes, renderers and other applications can then choose whether they want to use that information or not. Here in germany we are simply not asking if something should be included! People in densely mapped areas are starting to map single trees and litter bins - not all of us doing so, but that's not the point here. How this should be tagged depends on what's on the ground. Please have a look at: http://wiki.openstreetmap.org/index.php/Map_Features It indicates to use highway=service together with service=driveway. Funnily enough, I don't have a clear understanding what a driveway actually is, seems to be an american english specific term? It's typically a piece of pavement that connects the road with peoples garage door. Of course, the pavement and the garage are optional. In German I would probably say Grundstückseinfahrt. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 26 languages
2009/1/25 Colin McGregor colin.mc...@gmail.com On 1/24/09, Frederik Ramm frede...@remote.org wrote: Hi, Lars Aronsson wrote: After Portuguese and Afrikaans have been added, there are now 28 languages. But of the largest Wikipedia languages, we're still missing Japanese (5th biggest) and Chinese (12th). Why bother educating the Chinese about OSM when they will be jailed trying to contribute? Might be best not putting any Indian languages up though, mapping there will get you jailed, and may be best removing the English too, I wouldn't like to think what could happen or where you'd be sent if you were spotted doing something suspicious like walking around with a GPSr, a voice recorder, a camera and a backpack in at least the US, especially if you looked 'foreign'... There isn't even a great firewall in those locations to protect people from seeing things they shouldn't ;) The answer is simple and obvious, not all Chinese speaking people live in China. I live in Toronto, Ontario, Canada, and some 11% of the population (over 280,000 people) is of Chinese decent, and relevant for the likes of a Wikipedia entry, manages to support three daily Chinese language newspapers... So, for the benefit of oversees Chinese a Wikipedia entry would be a good thing (the more mappers the better in my books). There are 100s of thousands of Chinese students studying abroad... figures I've seen suggested 12 in the EU alone in 2007... The US, Canada and Australia are also common destinations for Chinese students looking to study abroad, with the US apparently having over 8 Chinese students in 2007-2008... Of course, there are stats such as this 'The number of people studying abroad totalled 1.2117 million from 1978 to 2007, among which 319,700 have already returned.' which suggests that between 1978 and 2007 1.2 million people went to study abroad and 90 haven't returned yet... So, there are plenty of Chinese people outside China who's first written language is Chinese... But, within China, while there has been the obvious press that people have been fined and expelled for illegal mapping, the stories are mostly specifically about foreign nationals who've entered China only to perform surveying, including surveying airports/airbases... China has massive amounts of effort going into mapping, with billions ($ I think) being put into projects in recent years to make accurate enough maps that they can be used with GPS devices... Not all the efforts are state based though... There is also a lot of mapping for profit going on... GPS devices are very popular with satnav in car devices very common... A pretty massive number of brands exist, all competing with very similar products, map data comes from all over the place and up to date POIs are typically seen as one of the most important aspects of the data, something especially relevant considering the rate of change and development... There and lots of companies involved, all trying to build their own dataset for profit... Some licensed, but most probably not... And this is just part of the situation with maps in China... A report last year some time said that there were over 1 websites in China that contained unauthorised maps, huge demand for mapping data and limited general availability of quality authorised data were I believe cited as a potential cause... 10 years ago there was not much in the way of publicly available maps, now there are maps everywhere... even on every street corner, at least in touristy places... Quality is still an obvious issue... Availability of data is still an issue, though state data is available more and more and is becoming more and more open, partly to encourage use of the official state data in preference to data from other sources... China's legal system is still growing, maturing and developing, like most things in China... Things are improving all the time... The place is not at all like is portrayed in most Hollywood movies, in many ways it's more free, open and in many cases commercial than you probably imagine... At the end of the day, for people in China, if the authorities don't want them to see a site on the internet, it'll get blocked... Wikipedia itself has been blocked for large amounts of time with the non-chinese versions coming and going and more recently the chinese version becoming available and staying available... There is still blocking of certain wikipedia pages where the content is deemed unsuitable either by the filtering software or the decision makers that control the filtering rules... So... If the information about OSM is put on wikipedia in Chinese, there are millions of people outside of mainland China that could find the translation useful, there are many more within China that could be interested to read about it even if they don't then go on to contribute and if it is considered to be unwanted by whichever people/departments make those choices, it'll get blocked
Re: [OSM-talk-nl] Openfietskaart.nl
Ronald, Dit komt doordat die ways getagged zijn met ncn_ref=LF3, ik weet niet wie dat zo gedaan heeft. Dit is bij andere routes niet gedaan. Ik vindt het eerlijk gezegd ook niet zo mooi, het is nogal overheersend, zeker als je wat verder uitzoemt. Deze route schiet in Zwolle-Zuid alle kanten op, lijkt erop dat wat ways gesplitst moeten worden. Ik zag trouwens nog een paar losse nodes getagged met ncn_ref nummers? In en rond Heino: http://www.openfietskaart.nl/?zoom=17lat=52.43429lon=6.22949layers=BF TTTFFFT. Groeten, Taede. -Original Message- From: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] On Behalf Of Ronald Sent: zondag 25 januari 2009 3:39 To: talk-nl@openstreetmap.org Subject: [OSM-talk-nl] Openfietskaart.nl ik zie op www.openfietskaart.nl dat de route LF3 tussen Zwolle en Dieren voorzien is van nummering. Dat smaakt naar meer. De overige routes zijn niet voorzien van nummering en daar moet je dus maar raden welke route het is. Is er een reden voor dat LF3 voorzien is, of is dat een vergissing? Ronald ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Brede wegen
Dit is niet bedoeld als kritiek of als voorstel tot wijziging, alleen illustratief. Kijk hier eens hoe (te) breed wegen gerenderd worden, als je het bijbehorende huis erbij tekent : (middenin het scherm , zijweg van abstwoude) http://tile.openstreetmap.nl/?zoom=16lat=51.97463lon=4.35065layers=B0 00F Gert Gremmen - Openstreetmap.nl (alias: cetest) image001.gif___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Suburb boundaries
I'm happy to follow this up with the ABS if no-one else has done so yet. cheers On Sat, Jan 24, 2009 at 5:02 PM, Luke Woolley lswool...@gmail.com wrote: Well, this is the copyright info displayed on the ABS website, which states that the data appears to be under the Creative Commons Attribution 2.5 Australia http://creativecommons.org/licenses/by/2.5/au/ licence which means we can copy, distribute, transmit and/or remix the data as long as it is attributed. If the data is implemented into OSM and is unchanged from the original data, Source: Australian Bureau of Statistics must be mentioned. If the data is a derivative of the original data, Based on Australian Bureau of Statistics data must be mentioned. But because we want to look over everything we would like to use in OSM with the finest of fine tooth combs, somebody should shoot off an email to * intermediary.managem...@abs.gov.au* intermediary.managem...@abs.gov.au and see what they say. 2009/1/24 James Churchill pel...@gmail.com James Churchill pel...@... writes: Looks like it's CC licensed; here's a link: http://www.abs.gov.au/websitedbs/D3310114.nsf/4a256353001af3ed4b2562bb00121564/70353d5dd53b0e2dca257522001e996c!OpenDocumenthttp://www.abs.gov.au/websitedbs/D3310114.nsf/4a256353001af3ed4b2562bb00121564/70353d5dd53b0e2dca257522001e996c%21OpenDocument - James Whoops, just noticed that link isn't explicit about what is CC licensed; here's another link: http://www.abs.gov.au/websitedbs/D3310114.nsf/Home/%C2%A9+Copyright?OpenDocument At the very least, it has contact details for the person to ask about the rights. - James ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Hausnummern
...und noch ein Mecker ;) Da ich mich grade ein wenig in die Erfassung von Hausnummern verbissen habe, irritiert mich mal wieder die Darstellung derselben. Mancherorts sieht man vor lauter Hausnummerklecksen nichts anderes mehr (Altstadt MG z.B. - sorry, hab grad keinen Link). War da nicht mal eine Änderung geplant? Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG die 3.
Gary68 schrieb: nach einigen guten tipps nun mal was richtiges zum vorzeigen. inkscape und ff zeigen nun alle straßen beschriftet. Opera im übrigen auch ;-) Danke für das nette Tool, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
BroadwayLamb schrieb: Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. da stimme ich dir voll und ganz zu. am besten würde mir aber gefallen, wenn die Hausnummern immer verschoben würden. es gibt so viele Objekte die diese überlagern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fitness-Center
Hallo! Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Nach meiner bescheidenen Meinung würde Darstellung Was geschieht eigentlich mit solchen und ähnlichen *Wünschen an die Renderer*? Wer ist das eigentlich: die Renderer? Wer sind die Macher, die diese gestalten? Wie ist der Kontakt zwischen diesen und dem Rest der OSM-Welt geregelt? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG ???
On Fri, Jan 23, 2009 at 07:13:03PM +0100, Tim 'avatar' Bartel wrote: Subject: Re: [Talk-de] SVG ??? Hi, Am 23. Januar 2009 18:37 schrieb Gary68 g...@gary68.de: WIE BEKOMME ICH DAS UNTER LINUX ZU SEHEN? Inkscape, gwenview, Gimp, ... (welches svg-faehige Linux-Programm kann es *nicht*?) Es gibt keine vernuenftige vollstaendig SVG implementation unter Linux. Inkscape ist as-good-as-it-gets ... Sobald man Text on a Path macht ist bei den meisten svg engines vorbei. Das habe ich mir fuer ti...@home mal angesehen weil inkscape einfach ein raeudiges stueck software ist was auch mal schnell 4-10GB (Ja Gigabyte) zum rendern braucht .. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
Tim 'avatar' Bartel schrieb: Ebenso werden die vielerorts erfassten sub_stations gar nicht (mehr?) gerendert. Dumme Frage: sub_stations werden momentan aber weder von Mapnik noch von Osmarender gerendert, oder? (Mir war auch gar nicht aufgefallen, dass die vorher mal gerendert wurden - ich bin ein großer Freund von power-tagging). Mapnik rendert die schon lange - zumindest als Area. Bei Osmarender bin ich mir nicht sicher. Ich weiß nur, daß die Darstellung der power lines bzw. towers dort auch schon mal besser war. Hier mal ein Link: http://www.openstreetmap.org/?lat=51.21249lon=6.45888zoom=17layers=B000FTFT http://www.openstreetmap.org/?lat=51.21249lon=6.45888zoom=17layers=B000FTFT Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Am 24. Januar 2009 02:25 schrieb Karl Eichwalder k...@gnu.franken.de: Das ist nicht das Problem des Mappers, sondern des Routers. Nein, das ist eine nicht rückwärtskompatible neuerung. Besser sollte man mappen, um alte anwendungen nicht zu beeinträchtigen: highway=construction contruction=motorway In Bau befindliche Teiche bekommen hier auch ein contruction=yes an das natural=water. ein natural=construction wäre auch ziemlich sinnfrei. Nein, nicht unbedingt. Wenn dir das alles gar nicht gefällt, dann verwende einen pseudo-namespace: contruction:natual=water Mal im Ernst, so bescheuert, wie ich Garrys mapping-für-Garmin-Aktionen(siehe Inseln und Wald) auch finde; construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zurückgebaut trifft die Sache einfach besser. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Ein Renderer könnte zum Beispiel alles, was diesen Zusatztag hat, halbtransparent, rot-weiß schraffiert oder mit dem Symbol eines Bier trinkenden Bauarbeiters versehen zeichnen, ohne sich um die Art des Objekts zu kümmern. Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] riverbank und wildbach
Hallo Hermann, im frühjahr für mehrere wochen und im sommer nach starkregen für ein paar stunden führen sie um grössenordnungen mehr wasser als die restliche zeit. _Küstenlinie_ Vergleichbares gibt es auch in Küstengewässern mit starker Tide, oder in flachen Küstengewässern: bei Flut sind sie unter Wasser, bei Ebbe fallen sie trocken. Dort werden (oder sollte) *zwei Küstenlinien* eingetragen: Küstenlinie LAT (bei niedrigst möglichem Wasserstand) http://wiki.openstreetmap.org/wiki/de:Lowest_Astronomical_Tide Küstenlinie NHN (Normalhöhennull) http://de.wikipedia.org/wiki/Normalhöhennull Das Gebiet dazwischen nennt man trockenfallend. Es sollte als blassgrüne Fläche gerendert werden. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Nein, das ist eine nicht rückwärtskompatible neuerung. Besser sollte man mappen, um alte anwendungen nicht zu beeinträchtigen: highway=construction contruction=motorway Ich finde, im jetzigen Zustand der Unordnung Rückwärtskompatibilität einzuführen äußerst kontraproduktiv. Das ist etwas, was man in vielen Jahren machen kann, wenn die ganzen Unstimmigkeiten im Tagging ausgemerzt sind. Ich will gar nicht dran denken, wie das jetzt ausschauen würde, wenn die gleiche nichtskalierende Methode auch bei oneway und access etc. verwendet worden wäre. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Markus schrieb: Nach meiner bescheidenen Meinung würde Darstellung Was geschieht eigentlich mit solchen und ähnlichen *Wünschen an die Renderer*? meist arbeitet die einer der Renderer in das style-file des osmarenders ein Wer ist das eigentlich: die Renderer? jeder der einen svn Zugang hat und sich da eingearbeitet hat. bin leider nur einer der ersteren ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Torsten Leistikow schrieb: Es gibt ein leisure=sports_centre. währe da nicht sport=sports_centre korrekter? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Hallo Sebastian, http://wiki.openstreetmap.org/wiki/Proposed_features/More_access_keys_and_values das ist nicht logisch: Entweder es ist nach Benutzern geordnet: highway=path + agricultural=yes + foot=yes Oder es ist in Access als Gruppe zusammengefasst: highway=path + access=agricultural + acess=foot aber bitte nicht beides oder gar durcheinander. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
Tim 'avatar' Bartel schrieb: Alles klar - ich habe die bisher nie als Area, sondern als Point gemappt. Als sub_station's mappe ich die Dinger, die größer sind als die hier: http://www.addicks.net/gallery/strom/DSCF0807_001 Also sowas hier und kleinere: http://www.addicks.net/gallery/strom/P3170111 In a residential area, these are typically little buildings the size of a garden shed, with about a metre perimeter of land around them, and a fence or wall with 'warning high voltage' signage. Die sind in der Regel zu klein um sie als Area zu erfassen. Oops, da gab es dann wohl eine Änderung beim Tagging, die mir entgangen ist. Aus allen meinen sub_stations sind dann neuerdings wohl stations geworden - also so was wie das hier: http://wiki.openstreetmap.org/wiki/Image:800px-Transmissionsubstation.jpg Ob diese Unterscheidung allerdings dem tatsächlichen englischen Sprachgebrauch entspricht, wage ich zu bezweifeln... Ein Umspannwerk im Hochspannungsbereich ist nach meiner Meinung eine substation. Die Schaltkästen aus deinen Beispielen - coole Graffiti übrigens ;) - habe ich bisher überhaupt nicht erfasst und würde das auch eher als switchbox / switch unit oder so bezeichnen. Jedenfalls sind die definitiv zu klein, um sie als area zu erfassen, da stimme ich dir zu ;) Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
BroadwayLamb broadwayl...@gmx.net wrote: seit einer der letzten ?nderungen f?llt mir auf, da? power=line im osmarender-layer nach meiner Meinung viel zu prominent dargestellt wird. Ansichtssache ;-) Ich wollte man_made=pipeline einbauen in Osmarender und suchte power als Muster (transportiert ja auch Energie... also warum nicht daran orientieren...) und ... ... suchte erstmal vergebens, weil die sich auf meinem Laptop-LCD kaum von so manchen Hintergruenden hier in der Gegend abhoben. Selbst vom Standardhintergund hoben sie sich kaum ab. Daher habe ich ein wenig experimentiert und das Grau etwas abgedunkelt und ihnen fuer dunkle Hinteruende eine helle Unterlage verpasst. Und nun sieht man sie auch, wenn sie ueber landuse=farm oder die pipelines durch den Wald laufen, wo ich ueber sie beim mappen von Waldwegen stolperte... Pipeline-Bsp.: http://www.informationfreeway.org/?lat=49.08lon=8.424zoom=16 Oel und Gas kreuzen sich dort. Wenn man nach link an den Waldrand geht und dann aufwaerts, findet man auch die powers, die ich kaum sah wegen div. dunkler Hintergruende... Die eigentlichen Landmarken, die riesigen Strommasten jedoch sind kaum erkennbar. Ebenso werden die vielerorts erfassten sub_stations gar nicht (mehr?) gerendert. Stimmt, um die tower wollt eich mich noch kuemmern, verschob ich erstmal, weil die woanders definiert wurden als im style selbst... Habe ich eben nachgeholt, Wenn mit frischen styles gerendert wird, sollten sie das gleiche Grau haben wie die Leitung: #808080 derzeit. sub_station scheinen in den styles nicht drin zu sein. Da waere ich aber unschuldig, falls die frueher drin gewesen sein sollten... Falls ich mit dieser Meinung nicht alleine dastehen sollte, dann w?re es nett, wenn das ein wenig angepasst werden k?nnte. Man muss ja nicht alles von Mapnik kopieren, aber da ist es perfekt gel?st Ohja, da sieht man sie noch besser, weil noch dunkler, soll ich? ;-) und nicht strichliert, also eigentlich noch prominenter... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Josias schrieb: Torsten Leistikow schrieb: Es gibt ein leisure=sports_centre. währe da nicht sport=sports_centre korrekter? Wenn man der bisherigen (nicht ganz trivialen :-) Logik folgt ist das schon ok. sport=xy gibt nur die jeweilige(n) Sportart(en) an. leisure=stadium, golf_course, pitch, ... gibt dann die jeweiligen *Sportstätten* an Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Dimitri Junker o...@dimitri-junker.de wrote: K?nnte man ihnen aber doch beibringen oder? Das sind doch nur Geraden oder kommen da auch Beziers vor? Bei Geraden sehe ich da nicht das gro?e Problem, Beziers sind etwas aufw?ndiger, im Notfall m??te man die Bezierkurve zuerst in Geradenst?cke wandeln und diese dann verschieben. In C w?rde ich das hinbekommen. Eben, das ist das Problem... Dat janze is nich in C programmiert... Oder in irgendeiner anderen Sprache, die mathematische Funktionen beherrscht... Letzteres ist das grundlegende Problem... Man muesste das ganze entweder voelllig neu programmieren in einer Sprache, die die 4 Grundrechenarten beherrscht und paar trigonometrische Funktionen warren auch von Vorteil.. ;-) Oder einen geometrischen Zwischenprozessor dazwischen schalten, wie ich gestern meinte... Dann koennte man Linienstuecke parallel verschieben und die neuen Knoten aus den Kreuzungspunkten der verschobenen Stuecke berechnen. Ist aber auch nur suboptimal, weil viel Rechnerei, Datenmengenvermehrung und evtl. nicht ueberzeugendes Ergebnis, denn bei den Linienabrundungen an den Knoten wrden die Abrundungsradien nicht passen, was spaetestens auffaellt, wenn es ein sehr spizer Knick ist, und bei den Bezier-Kurven wird's knifflig... Das beste wird sein, wir ueberreden die SVG-Macher zu einem neuen Feature ;-) Allerdings: wenn man langfristig das Problem parallel verlaufender Linien loesen moechte, die vernuenftig parallel gezeichnet werden sollen (also der Fall, wo Radwege getrennt gemappt wurden) statt Teilueberlapungen ode Riesenluecken, je nach Zoomfaktor und gemappter Distanz, kommen wir um eine geometrische Vorprozessierung nicht drumrum... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
On Sat, Jan 24, 2009 at 09:17:49AM +0100, BroadwayLamb wrote: Subject: [Talk-de] Hausnummern ...und noch ein Mecker ;) Da ich mich grade ein wenig in die Erfassung von Hausnummern verbissen habe, irritiert mich mal wieder die Darstellung derselben. Mancherorts sieht man vor lauter Hausnummerklecksen nichts anderes mehr (Altstadt MG z.B. - sorry, hab grad keinen Link). War da nicht mal eine Änderung geplant? Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. Die erfahrung zeig so ein bischen das das was nicht gerendert wird auch nicht erfasst wird. D.h. das Hausnummern gerendert werden ist schon wichtig und ich finde osmarender ist schon okay - Mapnik ist die schoene aufgeraeumte Karte fuer Schwiegermutter und Osmarender die wir malen alles fuer die mapper karte ... Und wenn es da mal ein wenig voller wird in den innenstaedten ist das doch okay. Ich finde die neue errungenschafte die Hausnummern die sich den node mit amenitys teilen, rechts neben das eigentliche amenity symbol zu rendern doof. Damit kommt es oft dazu das mitten auf der Straße Hausnummern stehen: http://www.informationfreeway.org/?lat=51.77559071199572lon=8.316189079860315zoom=17layers=BF000F Das Cafe Zur Linde und die Turmschänke haben jeweils eine Hausnummer nur wird die nach rechts verschoben und direkt auf der Straße gerendert. Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Martin Simon grenzde...@gmail.com wrote: construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zur?ckgebaut trifft die Sache einfach besser. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Ich finde das jetzige System mindestens genauso logisch: highway=footway Fuzsgaenger highway=cycleway Cyclisten highway=track Traktoren highway=residential Residierende unterwegs highway=primary Primaten? ;-) highway=construction Konstruktionsmaschinen am Werkeln kighway=planned Verkehrsplaner laufen ueber die Wiese highway=disused Disteln als user... ;-) Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Nun ja... Jede einfache Anwendung muesste sich erstmal durch eine Ist nicht ...-Orgie durchwurschteln... Garry sagt ja was von Garmin-Karten. Dazu fand ich mkgmap im Netz, vermutlich nimmt er das? Dessen styles sind bisher sehr einfach strukturiert: highway=cycleway [0x16 resolution 23] und so weiter... Wollte man da construction=yes, planned=yes, disused=yes, abandoned=yes, ... alles so verarbeiten, dass normale Garmin-Karten-Anwender (auszer Garry mit seinen Spezialwuenschen, die meiner Vermutung nach kontraer dazu sind) dort wirklich nur nutzbare Straszen sehen und keine Hirngespinste, die bisher nur in Planerkoepfen rumspuken, muesste man in jeder Zeile einen Wust von construction = ~|no ... dazwischen setzen, wenn das ueberhaupt so geht, keine Ahnung... Auch im Osmarender ware eine ganze Kaskade von rule-else regeln neotig, die die ganzen highway-Regeln unuebersichtlich macht, waehrend jetzt normal/construction/... voneinander getrennt sind. Ganz chaotisch wuerde es, wenn man beides parallel supporten wollte, was mind. fuer eine Uebergangszeit noetig waere... Die Zahl der Werte bleibt dagegen bei beiden Modellen gleich highway=art status=yes und highway=status status=art sind jeweils immer 2 MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
Heiko Jacobs schrieb: BroadwayLamb broadwayl...@gmx.net wrote: Man muss ja nicht alles von Mapnik kopieren, aber da ist es perfekt gel?st Ohja, da sieht man sie noch besser, weil noch dunkler, soll ich? ;-) und nicht strichliert, also eigentlich noch prominenter... Ja gerne, aber nicht nur dunkler, sondern vor allem viel dünner und als durchgehenden Strich - wie solche Kabel halt aussehen. Im jetzigen Zustand wundere ich mich immer über den vermeintlichen (gestrichelten) Trampelpfad mitten durch die Pampa, der sich bei näherem Hinsehen dann als power line herausstellt. ;) Danke übrigens für die Pipelines. Wenn die jetzt tatsächlich gerendert werden, dann fallen mir spontan einige Stellen ein, bei denen ich dann doch etwas Mapping-Energie investieren könnte. Ja, ja ich weiß - wir mappen nicht für den. Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
On Sat, Jan 24, 2009 at 11:44:47AM +, Heiko Jacobs wrote: Markus liste12a4...@gmx.de wrote: Was geschieht eigentlich mit solchen und ?hnlichen *W?nschen an die Renderer*? Wer ist das eigentlich: die Renderer? Theoretisch jeder mit svn-account, zumind. bei Osmarender Wie es bei Mapnik laeuft, weisz ich noch nicht... Kann man da auch einfach im style rumpfuschen ;-) und hochladen??? Steve Chilton s.l.chil...@mdx.ac.uk kümmert sich hauptsächlich um die Mapnik Styles. 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] riverbank und wildbach
Hallo, Markus schrieb: _Küstenlinie_ Vergleichbares gibt es auch in Küstengewässern mit starker Tide, oder in flachen Küstengewässern: bei Flut sind sie unter Wasser, bei Ebbe fallen sie trocken. Dort werden (oder sollte) *zwei Küstenlinien* eingetragen: Küstenlinie LAT (bei niedrigst möglichem Wasserstand) http://wiki.openstreetmap.org/wiki/de:Lowest_Astronomical_Tide Küstenlinie NHN (Normalhöhennull) http://de.wikipedia.org/wiki/Normalhöhennull Das Gebiet dazwischen nennt man trockenfallend. Es sollte als blassgrüne Fläche gerendert werden. http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline sagt: A way drawn along the coastline; this should ideally be positioned at the average high tide line. Solange das mittlere Hochwasser der Standard ist, sind LAT und NHN irrelevant für die Bestimmung der Küstenlinie. Übrigens sind geodätische Bezugsflächen generell unbrauchbar für die realitätsnahe Abgrenzung von Land und Wasser. Die Regeln für die zweite Künstenlinie sollte besser ausgearbeitet und dann international diskutiert sowie dokumentiert werden, bevor hier so getan wird, als sei das der Standard. @Markus: Lass uns erst mal die eine Küstenlinie an das mittlere Hochwasser (und zwar das örtliche!) anpassen, bevor wir es komplexer machen - es sei denn, du möchtest vor Ort die Arbeit tun. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
BroadwayLamb schrieb: Danke übrigens für die Pipelines. Dito! Ich freue mich jedesmal, wenn ich mal wieder auf der Karte ein neues Feature finde. Wenn die jetzt tatsächlich gerendert werden, dann fallen mir spontan einige Stellen ein, bei denen ich dann doch etwas Mapping-Energie investieren könnte. Ja, ja ich weiß - wir mappen nicht für den. Bitte den häufig geäußerten Spruch: wir mappen nicht für den Renderer nicht falsch verstehen :-) In erster Linie bedeutet das, wir mappen Dinge nicht anders als sie in der Realität sind, nur damit diese irgendwie auf der Karte erscheinen. Wenn du jetzt anfängst, die Pipelines in deiner Gegend als Stromleitungen einzutragen weil nur diese auch auf der Karte auftauchen ist das von den Daten her ja schlicht falsch - und das ist sehr schlecht. Es ist aus meiner Sicht aber völlig klar, daß Dinge die auf der Karte zu sehen sind allgemein viel eher gemappt werden als Dinge die nur so in der Datenbank stehen. Das ist auch genau der Grund, warum ich beim JOSM versuche möglichst viele der Features darzustellen. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Hallo, Dat janze is nich in C programmiert... hab ich mir gedacht, worin ist es denn programiert? Oder in irgendeiner anderen Sprache, die mathematische Funktionen beherrscht... Wie es gibt sprachen die nicht rechnen können? Da ich nicht weiß wie es läuft spekulier ich mal schnell über ein paar Möglichkeiten und Du sagst was realistisch wäre: -alles neu: funktioniert ist aufwändig -wenn die Software ein anderes Programm aufrufen kann könnte man ein externes Programm schreiben das in irgendeiner Form eine Kurve erhält und den Abstand und daraus eine neue Kurve erzeugt -Man schreibt ein neues Programm, welches das SVG der bestehenden Software weiterverarbeitet. Das ist natürlich Pflickschusterei, wäre aber eine schnelle Möglichkeit, und die Routinen zur Verschiebung könnten ja später in einer vernünftigen Software eingebaut werden. Je nachdem was man der Software beibringen kann könnte sie entweder ein Zusatztag einfügen oder es könnten Eigenschaften wie Farbe, gestrichelt,... mißbraucht werden Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG ???
Hallo, Es gibt keine vernuenftige vollstaendig SVG implementation unter Linux. Nach allem was ich in den letzten Tagen gesehen habe würde es mich wundern wenn es nicht recht einfach wäre einen SVG nach PS Konverter zu schreiben, also gibt es da bestimmt schon was. Und das PS dann ansehen sollte unter Linux kein Problem sein. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo Frederik, danke für Deine wertvollen und detaillierten Vorschläge zur Qualitätssicherung! Ich denke, das sind zukunftsträchtige Ideen, die sich möglicherweise schon in den nächsten OSMXapi-Versionen wiederfinden könnten. - Aktuell besteht ja noch keine Notwendigkeit, denn entsprechend sicherheitsbedürftige Daten liegen noch nicht grossflächig vor (aber das kann sich bei der schnellen Entwicklung von OSM ja bald ändern). _sicherheitsrelevante Objekte_ Mein Wunsch ist es, für sicherheitsrelevante Objekte, beispielsweise ein Leuchtturm für die Schifffahrt, verlässliche Daten zu haben. Meine Idee war, dies über eine besonders sorgfältige - *Qualitätsprüfung bei der Dateneingabe*, und über eine - *red-only*-Funktion der geprüften Daten bei der Datenausgabe zu erreichen. Änderungen an den Daten würden dann genauso wie bei der Dateneingabe die Qualitätsprüfung durchlaufen. Damit wäre gewährleistet, dass Anwendungsprogramme bei sicherheitsrelevanten Objekten nur qualitätsgeprüfte Daten erhalten. Nach aussen würde sich nichts ändern: Der Benutzer sieht im Editor die vorhandenen Daten, ändert sie oder fügt neue hinzu, diese werden geprüft und anschliessend neu angezeigt. Grundsätzlich halte ich es für gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen. Warum? Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu Qualität am Ausgang zu überprüfen und Ausschuss ggf. wegzuschmeissen). Checksummen-Algorithmus Das ist ein wertvolles Instrument für die Eingangsprüfung, beispielsweise zum Vergleich mit amtlichen Daten (zur sicheren Prüfung von Abweichungen), oder mit bestehenden Daten (zur Verhinderung von Tippfehlern, versehentliches Verschieben, etc.). Programme, die Daten auslesen, könnten die Checksumme prüfen und wenn sie nicht zu den Koordinaten passt, den Node ignorieren (oder den Benutzer irgendwie warnen). Eine Ausgabeprüfung würde - Daten einzelner Objekte nicht ausliefern (bei Fehlern) - den Download verlangsamen (durch die Prüfung) sich gegen *absichtliche* Datenänderungen schützen, trust-Weg: Man hat eine Liste von Benutzern, denen man vertraut, und bei bestimmten Objekten verlässt man sich ausschliesslich auf diese Leute Das entspricht der von mir vorgeschlagenen sorgfältigen Eingangsprüfung, und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Qualität bedingt definierte Ziele und Parameter. Sie entsteht durch Menschen, die diese verstanden haben und denen man vertraut diese umzusetzten, verfeinert durch ein Vier-Augen-Prinzip. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Der Nachteil dabei ist, dass die Eingangsprüfung Zeit braucht, eine Änderung in der DB also nicht in Echtzeit erfolgt. Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). Wir würden zugleich ein Tool a la OSM-Inspector oder OSM Mapper einsetzen, um schnell zu sehen, wenn irgendjemand eines von unseren Objekten ändert, um diese Änderung dann auch prüfen und abstempeln zu können. In der Eingangskontrolle wären solche Instrumente sehr effizient. Krypto-Tokens, basierend auf public key-Kryptographie. Die Anwendung habe ich noch nicht ganz verstanden. Aber ich erinnere mich, dass ECDIS zur Verifizierung ihrer Daten solche Methoden anwendet (aber eher aus ökonomischen Gründen). Die OSMXapi hat übrigens ein interessantes Feature, das in diese Richtung geht (siehe http://wiki.openstreetmap.org/index.php/Osmxapi#RSS_Feed). Hier wird ein bestimmtes Tag ausgewertet, mit dem Benutzer ein Objekt auf ihre Watchlist setzen können, und selbst wenn andere Benutzer dieses Tag entfernen, wird OSMXapi diese Änderung ignorieren. Es gibt also die Möglichkeit, bei völliger Freiheit in der zentralen OSM-Datenbank, trotzdem einen gefilterten Mirror zu betreiben, der Änderungen nur dann übernimmt, wenn sie nach irgendwelchen programmierten Regeln zulässig sind. Das klingt interessant! Und vielleicht sind gefilterter mirror ja dasselbe wie read-only für einen keinen Bereich von sicherheitsrelevanten Daten Gruss, Markus PS: ich verstehe nicht so viel von DB-Design - aber so rein gefühlsmässig erscheint mir eine
Re: [Talk-de] construction
Heiko Jacobs schrieb: Martin Simon grenzde...@gmail.com wrote: construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zur?ckgebaut trifft die Sache einfach besser. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Ich finde das jetzige System mindestens genauso logisch: highway=footway Fuzsgaenger highway=cycleway Cyclisten highway=track Traktoren highway=residential Residierende unterwegs highway=primary Primaten? ;-) highway=construction Konstruktionsmaschinen am Werkeln kighway=planned Verkehrsplaner laufen ueber die Wiese highway=disused Disteln als user... ;-) Es ist schon längst Zeit das hier auferäumt und der highway - Tag für ways nicht als Zustands-Tag missbraucht wird! Die Einführung von highway=construction war(bzw. ist immer noch) eine Notlösung um nicht freigegeben Strassen nicht als fertig zu rendern. Das ist das einzigste Problem an der Geschichte warum es hier diese Unstimmigkeiten gibt und weiter geben wird so lange da so in den Renderern implementiert ist. Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Nun ja... Jede einfache Anwendung muesste sich erstmal durch eine Ist nicht ...-Orgie durchwurschteln... Garry sagt ja was von Garmin-Karten. Dazu fand ich mkgmap im Netz, vermutlich nimmt er das? Ich nehme die Karten von Computerteddy(für Garmin,TTQV), NaviPowm,... und möchte mir nicht einen eigenen Karten-Style basteln sondern eine allgemeine Darstellung verwenden wie sie seit jeher auf Papierkarten üblich ist - notfalls - falls die gestrichelte Darstellung nicht umgesetzt ist - mit einer entpsrechenden Beschriftung über das name-Tag sowie einer kurzen Unterbrechung im Übergang zum bestehenden Strassennetz darauf hinweisen dass diese Strasse nicht freigegeben ist ! Die Zahl der Werte bleibt dagegen bei beiden Modellen gleich highway=art status=yes und highway=status status=art sind jeweils immer 2 Nur dass man im ersten Fall eine saubere Trennung zwischen highway-Typ und Status hat und im zweiten Fall erst prüfen muss ob es ein Status oder eine Strassenkategorie ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorschläge zur öonvkarte.de
Hallo Melchior. Zuerst einmal herzlichen Dank zu der wirklich sehr gelungenen ÖPNV-Karte! Neben der Möglichkeit die Liniennetze zu sehen ist Dir auch der restliche Style IMHO sehr gut gelungen. Wirk aufgeräumt und sehr stimmig! Ich habe ein paar Kommentare, Vorschläge und Bitten zu der Karte. Ich werd' diese Mail auch als Kopie an die Talk-DE schicken, damit sich andere dazu äußern können. 1. Farbgebung der Linien Momentan finde ich sind die dunklen Tram/UBahn-Linien zu prominent, vor allem gegenüber den kaum sichtbaren hellen Zugstrecken. Zudem sind Ubahn und tram kaum zu unterscheiden, Verkehren aber in einem ähnlichen Kontext. Mein Vorschlag: - light_rail werden blau (wie jetzt tram) mit dünner Linie. - train werden grün (wie jetzt light_rail) mit dicker Linie, evtl etwas dunkler. - bus bekommt eine dünne rote Linie - tram wird orange (etwas dunkler als jetzt train) und bekommt eine dickere Linie als Bus. - subway wird violett (wie jetzt ferry) und eine dünne Linie. - ferry könnte das dunkle blau der jetzigen subway bekommen. Gründe: - Grün und blau sind relativ dominant auf der Übersichtskarte, das entspricht der überregionalen Bedeutung des Zug-Netzes. - Rot und Orange und violett harmonieren gut miteinander (gehören alle zum lokalen Verkehr) sind aber gut voneinander zu unterscheiden (auch für Farbenblinde). - Die dickeren Linienstärken der tram im lokalen, bzw train im überregionalen Bereich heben ihre Bedeutung hervor. - train und light_rail verkehren meist ebenso auf der selben Trasse wie tram und bus im lokalen Kontext. Dies ist ein weiterer grund für die veränderte Linienstärke: Wenn ein Straßenabschnitt etwa sowohl von tram als auch von bus befahren wird, sehen wir eine feine rote Linie mit einem orangenen Rand für die tram. Das eine überdeckt nicht mehr das andere. 2. Farbgebung der Haltestellen == Analog zu obigem Farbschema könnte man auch bei den Haltepunkten verdeutlichen, welche Fahrzeugart wo hält. Nicht in ein Netz eingebundene Halte sind wie jetzt weiß. Stationen wo ein Bus hält bekommen einen relativ kleinen roten Punkt. Solche mit Tram-Halt einen orangenen Kreis außen rum. (subway einen violetten Punkt) Analog mit train und light_rail. Auf diese Weise kann man leicht sehen, welche ÖPNV-Art wo hält. 3. Umgang mit Haltestellen-Relationen = Vielleicht hast Du mitbekommen, das ich vor kurzem einen Vorschlag gemacht habe, wie man Haltestellen als Relation möglichst vollständig abbilden kann. Hintergrund: Momentan gibt es teilweise 4 oder mehr Haltepunkte für eine Station, entsprechend hässlich sieht es auf der Karte aus, wenn der Stationsname 4 mal auftaucht. Teilweise wird aber auch nur ein einziger Node gemappt für manchmal weit auseinanderliegende Haltepunkte. Zusammenfassung meines Vorschlages: Es gibt mindestens einen Halt mit highway=bus_stop, bzw. railway=station/halt. Dieser liegt AUF dem entsprechenden Weg. Dieser Punkt wird entsprechend in die Route-Relationen aufgenommen. Zudem werden die Orte des Haltestellenschildes/Wartehäusschens/Bahnsteigs NEBEN den Fahrweg an ihrer tatsächliche Position markiert und mit highway=platform markiert (inzwischen tendiere ich allerdings immer mehr zu amenity=platform). Dies alles wird in eine Relation type=site;site=stop_area gepackt und mit Namen, Operator etc versehen. Dieses Schema gilt für alle Systeme (bus,tram,train,...). Vorteile (für Karten wie Deine): Auf niedrigen Zoom-Stufen ränderst Du die vielen zusammengehörigen Haltepunkte als eine einzige Entität, etwa im Schwerpunkt der Relationsmitglieder - Nur noch ein Punkt/Name je Station. In höheren Zoomstufen kannst Du an der Stelle jeder einzelnen Plattform entsprechend ein kleines H-Symbol anzeigen, so dass ich als Nutzer einen genaueren Blick auf die Situation vor Ort haben kann. Wenn Du es interessant findest und es nicht unschaffbar ist, wäre es toll, wenn Du Unterstützung für dieses Schema einbauen könntest. Ich würde mich freuen, wenn wir da zusammen etwas hinbekommen würden. Ich helfe auch gerne, muss allerdings dazu sagen, dass ich mit Rendering noch nie etwas gemacht habe. Also, her mit Kommentaren. Am besten über die Liste. Gruß, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Gerrit Lammert schrieb: 1. Farbgebung der Linien [...] - Die dickeren Linienstärken der tram im lokalen, bzw train im überregionalen Bereich heben ihre Bedeutung hervor. Dem möchte ich ganz stark wiedersprechen, denn bei uns in Berlin spielt der Bus eine wesentlich größere Rolle als die Straßenbahn, die außerdem größtenteils nur im Ost-Teil der Stadt vorhanden ist und aufgrund des Verkehrsrisikos nicht grade beliebt ist und daher IMHO an Bedeutung verliert. - train und light_rail verkehren meist ebenso auf der selben Trasse wie tram und bus im lokalen Kontext. Hier in Berlin spielt train (also Regionalbahn) im ÖPNV kaum eine Rolle und wird daher auch auf den meisten Karten dünn dargestellt. Dies ist ein weiterer grund für die veränderte Linienstärke: Wenn ein Straßenabschnitt etwa sowohl von tram als auch von bus befahren wird, sehen wir eine feine rote Linie mit einem orangenen Rand für die tram. Das eine überdeckt nicht mehr das andere. Das ist allerdings wieder sinnvoll, da dort, wo eine Tram fährt si klar das Straßenbild dominiert. 3. Umgang mit Haltestellen-Relationen Ich finde aus auch Sinnvoll der Übersicht halber zusammengehörige Sationen entsprechend zu verarbeiten. Wichtiger fände ich noch die Richtung (forward, backward) einer Haltestelle zu markieren, z.B. mit solch einem Dreieck wie auf den Linien dann in den weißen Punkt rein. Schlussendlich ist die Gewichtung der Transportmittel (dicke/dünne Linie) sehr schwierig, da man die lokalen Umstände berücksichtigen muss, die von Stadt zu Stadt und von Stadt zu Land unterschiedlich sind. Ich finde die Karte so schon sehr gut. Gruß, Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Markus schrieb: Hallo Sebastian, http://wiki.openstreetmap.org/wiki/Proposed_features/More_access_keys_and_values das ist nicht logisch: Entweder es ist nach Benutzern geordnet: highway=path + agricultural=yes + foot=yes Oder es ist in Access als Gruppe zusammengefasst: highway=path + access=agricultural + acess=foot aber bitte nicht beides oder gar durcheinander. Gruss, Markus Also ich versuchs nochmal zu erklären: Die Schlüssel stellen eine Gruppe von Benutzern mit bestimmten Eigenschaften dar. foot=* für alle die zu Fuß gehen, motorcar=* für alle mit Auto, hgv=* für alle mit LKW. Die Werte legen die Art des Verkehrs fest, der für die jeweilige Gruppe stattfinden darf. 'yes' für vollkommen freie Benutzung, 'destination' für Anlieger-Verkehr, 'no' für garkeine Benutzung. motorcar=no, motorcycle=no, agricultural=yes erlaubt also die Benutzergruppe 'agricultural' für jeden Verkehr. Das entspricht (dem Namen und der Benutzung nach) am ehesten dem Zeichen 1024-17 (Kraftfahrzeuge und Züge, die nicht schneller als 25 km/h fahren können oder dürfen frei). Das ist ganz klar eine Gruppe mit einer bestimmten Fahrzeugeigenschaft. Es dürfen also (vermutlich) Traktoren und Mofas von jedem, aber keine Autos vom Bauern durch, auch wenn ihm das Feld neben dem Weg gehört. motorcar=agricultural, motorcycle=agricultural erlaubt für die Benutzergruppen 'motorcar' und 'motorcycle' den Verkehr 'agrictultural'. Das entspricht dem Zeichen 1026-36 (Landwirtschaftlicher Verkehr frei). Hierbei handelt es sich nicht um eine bestimmte Gruppe mit einer Fahrzeugeigenschaft, sondern um eine Art des Verkehrs, die freigegeben wird. Hier darf also der Bauer zu seinem Feld fahren, egal ob mit dem Auto, dem Motorrad oder dem Traktor, während aber andere Motorfahrzeuge nicht mehr durch dürfen. Würde man nur agricultural=yes für beides benutzen, DANN wäre es eigentlich durcheinander und unlogisch, weil es entgegen der bisherigen Aufteilung geht. Dann müsste man auch destination=yes oder private=yes schreiben können. Wem die Unterscheidung egal ist, dem steht es natürlich weiterhin frei zu benutzen was er will.. :) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausbleibende Löschungen im Wiki
Hallo, On Friday 23 January 2009 23:18:42 Frederik Ramm wrote: Gibt es hier 1-2 Leute auf der Liste, die gerne (einer von mehreren) Sysops beim OSM-Wiki sein würden und sich dann u.a. um solche Sachen kümmern? Es gibt derzeit keine Sysops, die deutsch können, und das ist etwas wenig. Grant hat mich gefragt, ob ich 1-2 Leute empfehlen koennte. Ich würde mich nicht unbedingt darum reißen. Ich habe auch so schon eine ganze Menge zu tun, aber wenn sich sonst keiner findet, könnte ich dieses mit erledigen, da ich die recent changes sowieso schon den ganzen Tag beobachte. Gruß Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo, Markus wrote: Grundsätzlich halte ich es für gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen. Warum? Weil dies eine Macht bei jenen konzentrieren wuerde, die entscheiden, was gesperrt wird und was nicht und wer etwas bearbeiten darf. Solche Machtkonzentration fuehrt fast immer zu einem oder mehreren der folgenden negativen Effekte: * einige Leute fuehlen sich besonders wichtig, es bilden sich Machtstrukturen, Entscheidergremien, Abstimmungen, Anfechtungen von Abstimmungen, Rauswuerfe von Gremienmitgliedern, Anfechtugen von Rauswuerfen und all das * einige Leute sind Flaschenhaelse, an denen immer alles haengenbleibt, und wenn sie mal in Urlaub oder im Real Life ueberarbeitet sind, geht nix mehr * es entstehen komplizierte Authentifikations-/Legitimationsverfahren und ein Ruf nach Sicherheit (wenn Du mit Deinem Account ploetzlich spezielle Bearbeitungsrechte hast, wird Dein Account auch ploetzlich besonders schuetzenswert - man darf dann nur noch Authentifizierung ueber HTTPS machen und solche Scherze); all das bindet Zeit und Arbeitskraft Wenn man hingegen am Ausgang kontrolliert, dann kann jeder Empfaenger selbst definieren, welche Art von Qualitaet er will, wem er trauen will und wem nicht und so weiter; an den zentralen Bottlenecks der Datenbank faellt dadurch keine zusaetzliche Last an, es muessen keine Listen privilegierter Benutzer gefuehrt werden, Editoren muessen nicht angepasst werden... Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu Qualität am Ausgang zu überprüfen und Ausschuss ggf. wegzuschmeissen). Diese Lektionen lassen sich m.E. auf OSM keinesfalls uebertragen, zumindest nicht pauschal. Bei OSM gibt es keine zentrale, allen gemeinsame Definition von Qualitaet; was der eine wegwirft, ist fuer den andren wertvoll (bsp. ein 1000m daneben liegender Leuchtturm - wenn ich nur analysieren will, wie die Leuchtturmdichte pro Quadratkilometer in verschiedenen Kuestengebieten ist, dann ist mir das wurscht). Das entspricht der von mir vorgeschlagenen sorgfältigen Eingangsprüfung, und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Eine Eingangspruefung wird es auf absehbare Zeit nicht geben. Dazu fehlen sowohl die technischen Mechanismen als auch der Wille. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Das wuerde eine Warteschlange von noch nicht genehmigten Aenderungen erfordern, zusammen mit einem Interface und einer privilegierten Personengruppe, die diese Aenderungen bestaetigt, samt Regeln, nach denen sich diese privilegierte Personengruppe konstituiert. Sowas sehen wir fruehestens 2011 und auch dann nur gegen meinen Widerstand ;-) Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). Sag das nicht, sowas waere recht leicht ueber ein modifiziertes OSMXAPI machbar (es uebernimmt einfach nur gestempelte). In der Eingangskontrolle wären solche Instrumente sehr effizient. Es wird keine Eingangskontrolle geben. Das widerspricht den Grundprinzipien von OSM. - Eine Eingangskontrolle gibt es bei Google Map Maker, soviel ich weiss. Das klingt interessant! Und vielleicht sind gefilterter mirror ja dasselbe wie read-only für einen keinen Bereich von sicherheitsrelevanten Daten In die Richtung koennte es gehen. Der Vorteil ist das basisdemokratische Element - jeder oder jede Gruppe entscheidet selbst, welche Art von Filterung sie wuenscht/wuenschen; sobald jemand sich bevormundet fuehlt, kann er eine eigene, abweichende Filterung vornehmen. Sind hingegen in der zentralen Datenbank nur gefilterte Daten, steht diese Option nicht mehr offen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
On Thu, 22 Jan 2009 12:31:39 +0100, Jutta Weisel ju...@weisel.de wrote: In Marburg ist das Uni-Klinikum privatisiert, nimmt man dann amenity=university oder amenity=hospital ? Noch ein Sonderfall: Wie taggt man ein MPI, das auf dem Campus der Uni steht? Hallo, ich würde amenity=university;hospital machen und in Deinem Spezialfall noch ergänzen operator=Rhön-Klinikum AG. Was das MPI angeht, habe ich ein proposal amenity=research_institution eingereicht (http://wiki.openstreetmap.org/wiki/Proposed_features/research_institution). Wurde aber zurückgewiesen, weil es im eigentlichen Sinne wohl keine Annehmlichkeit ist (was ich auch bei anderen für etwas fraglich halte). Kann ich auch nachvollziehen. Im Moment tendiere ich zu research_institution=yes. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Marc Schütz schue...@gmx.net writes: Ich finde, im jetzigen Zustand der Unordnung Rückwärtskompatibilität einzuführen äußerst kontraproduktiv. Ich sehe das anders. Viele städte in D sind straßenmäßig fertig und in vielen regionen sind auch schon alle hauptverbindungen drin. Da sollte man sich bemühen, nicht noch mehr chaos anzurichten. Wem das mit highway=construction gar nicht zusagt, möge wenigstens highway=road verwenden. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Heiko Jacobs schrieb: SVG kann das offenbar nicht loesen... Gibt es andere Moeglichkeiten, parallel verschobene Linien zu erzeugen irgendwo im Prozess zwischen OSM-Daten auslesen und SVG erzeugen in Osmarender (und Mapnik irgendwann auch)? Vielleicht ein geometrischer Vorprozessor zwischen API und Renderern? SVG an sich hat kein Pfad-Attribut für Offsets, das ist richtig. Allerdings wäre es kein allzu großer Aufwand eine entsprechende Funktion in den Osmarender zu integrieren, sofern man sich an die ORP Variante hält. In welchem Umfang im Moment noch die ältere XSLT Variante in Betrieb ist kann ich allerdings nicht sagen. Das Mapnik keine Unterstützung dafür hat ist für mich etwas verwunderlich. Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, wobei dies in der Momentan vorliegenden Version auch nur im Rastergrafik-Modus funktioniert. Soweit ich gehört habe soll sich das im nächsten Release auch auf die SVG Ausgabe auswirken. Andererseits ist Cobra im Moment noch nicht so Recht für den produktiven Einsatz zu empfehlen. Frederik Fischer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG ???
Mit Firefox 3.1b2 unter Windows wird es ohne Fehlermeldung dargestellt. Jedoch kann ich da ja keine Ansichtseinstellungen vornehmen. Ciao André Am 23. Januar 2009 18:37 schrieb Gary68 g...@gary68.de: Hi, wer Interesse hat, mal bei http://www.gary68.de/osm/hof.svg vorbeisehen. DOWNLOAD!, DANN GRAFIKPROGRAMM BETA! - gruppen sind drin - straßen sollten zumindest teilweise beschriftet sein - wege sind zusammenhängend als polyline drin. aber... - wie kann ich die gruppen (in gimp) ein/ausschalten? - firefox steigt gleich aus wegen textPath element. - meine prgs zeigen die beschriftungen nicht. kann an den renderern liegen. bei tests hats auch nur der adobe svg... gebracht. schade, weil ich das ergebnis nicht sehen und verbessern kann. WIE BEKOMME ICH DAS UNTER LINUX ZU SEHEN? ciao Gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Hi Philipp. Philipp Hannasky wrote: - Die dickeren Linienstärken der tram im lokalen, bzw train im überregionalen Bereich heben ihre Bedeutung hervor. Dem möchte ich ganz stark wiedersprechen, denn bei uns in Berlin spielt der Bus eine wesentlich größere Rolle als die Straßenbahn, die außerdem größtenteils nur im Ost-Teil der Stadt vorhanden ist und aufgrund des Verkehrsrisikos nicht grade beliebt ist und daher IMHO an Bedeutung verliert. Berlin ist ein Sonderfall, weil es diesbezüglich ja eher zwei verschiedene Städte sind. Ich denke global hat eine Straßenbahn-Linie auf gleicher Strecke eher weniger Haltepunkte als eine normale Buslinie (Expressbusse mal außen vor). Aber selbst für Berlin: Damit kein optisches Ungleichgewicht entsteht habe ich extra die Farbgebung so vorgeschlagen wie beschrieben. Die jeweils dickere Linie sollte die jeweils unscheinbarere Farbe bekommen. So denke ich nicht, dass eine etwas dickere Linie in sanftem Orange eine schmale aber kräftige rote Linie dominiert. Als Vergleich der Farben siehe hier: http://www.öpnvkarte.de/?lat=53.86487lon=10.67328zoom=16 Ich finde hier dominiert das Rot (was ich an dieser Stelle unangebracht finde, daher mein Vorschlag). Wenn Du Dir jetzt vorstellst, das das rote etwas schmaler und vielleicht noch etwas kräftiger wäre, sehe ich da kein Problem... Hier in Berlin spielt train (also Regionalbahn) im ÖPNV kaum eine Rolle und wird daher auch auf den meisten Karten dünn dargestellt. Also wir taggen ja nicht für den Renderer, aber noch weniger taggen wir für Berlin. :) Im übrigen ist nach Kartenlegende light_rail der Regionalzug und train der Schnellzug. Letzterer ist aber in Berlin anscheinend noch nicht gemappt. Light_rail scheint auch insgesamt eher für S-Bahn verwendet zu werden, während REs bereits als train gelten. Aber darum was wie benannt wird, geht es hier ja nicht... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Hallo, Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, Cobra hab ich ja noch nie gehört, und die deutsche Wikipedia weis dazu auch nur, daß es eine Programiersprache ist. Ging es nicht noch exotischer? Aber egal, was meinst Du mit Offset? Eine einfache Translation reicht ja nicht. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Garry wrote: Ach ja - bei den von mir erfassten Daten verhindere ich die Router-Fehlfunktion zuverlässig in dem ich die in Bau/Plannung befindliche Strassen nicht an öffentliche Strassennetz anschliesse (kleine Unterbrechungen der Ways) - leider wird das von einigen übereifrigen Taggern immer wieder repariert so dass es dann zu dem Router-Problem kommen kann. Lass die Straszen doch verbunden und setzt einfach ein access=no. Grusz Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
@Gerrit: Hast du dich da schon mal mit den international an diesem Thema interessierten OSMlern in der Traffic/Transit-Liste kurzgeschlossen? Ich meine es gibt da ja inzwischen Bestrebungen zu international stimmigen Symbolen und Kartendarstellungen. Vielleicht könnte das also gleich richtig umgesetzt werden. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
wie waers denn mit folgendem schema (aehnlich dem, was schon vor ein paar monaten diskutiert wurde): access:gruppe[optionale einschraenkungen] = art des verkehrs beispiele: das klassische weisse schild mit rotem rand (zeichen 250): access:vehicle = no zeichen 250 mit zusatzschild anlieger frei: access:vehicle = destination zeichen 250 mit zusatzschild fahrraeder frei: access:vehicle = no access:bicycle = yes zeichen 251: access:motorcar = no zeichen 260 mit zusatzzeichen 22-6 h: access:motorcar[2200-0600h] = no access:motocycle[2200-0600h] = no zeichen 262 mit 5,5t drauf und zusatzschild lieferverkehr frei: access:vehicle[5.5t] = delivery analog fuer andere kombinationen... meinungen? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Dimitri Junker schrieb: Hallo, Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, Cobra hab ich ja noch nie gehört, und die deutsche Wikipedia weis dazu auch nur, daß es eine Programiersprache ist. Ging es nicht noch exotischer? Aber egal, was meinst Du mit Offset? Eine einfache Translation reicht ja nicht. Dimitri http://wiki.openstreetmap.org/index.php/Cobra Dieses Cobra meinte ich. Mit Offset meine ich eine Projektion des Pfades um einen bestimmten Betrag nach rechts oder links. Eine einfache Translation würde ja, wie von dir erwähnt, nicht ausreichen. ( http://osm.studio-24.net/images/cobra/path_offset.png ) ( http://osm.studio-24.net/images/cobra/dev08091603.jpg ) Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Guenther Meyer schrieb: wie waers denn mit folgendem schema (aehnlich dem, was schon vor ein paar monaten diskutiert wurde): access:gruppe[optionale einschraenkungen] = art des verkehrs beispiele: das klassische weisse schild mit rotem rand (zeichen 250): access:vehicle = no [...] analog fuer andere kombinationen... meinungen? jo :), hab ich auch im talk auf der wiki seite geschrieben. Ich halte es für sinnvoll bei neuen tags ein namespace mit einzuführen, hier halt access:. Das die alten access tags auch in diesem Schema besser aufgehoben wären steht dabei außer frage. Man wüsste halt bei access:hazmat=* gleich worum es ungefähr geht im gegensatz zu nur hazmat=*. Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tagging Schema mit Namespace was: Re: construction
Hallo, wäre nicht auch bei der highway=construction vs. construction=yes Problematik eine Lösung ein namespace tagging einzuführen. Man hätte dann: construction:highway=primary anstatt highway=construction und construction=primary bzw. highway=primary und construction=yes Vorteile: - Wenn man eine Karte nur mit im Bau befindlichen Objekten haben will, oder diese eben gar nicht haben will, sucht man nach dem construction: namspace und filtert über diesen. Vorgehen, wie bei construction=yes. - Ein Renderer muss nicht bei jedem highway etc. eine Abfrage starten ob ein construction=yes vorliegt um diesen zu Rendern, selbst wenn es keinen hat. Nur eine Abfrage des Renderers wie bei highway=construction (nicht 2 Abfragen wie bei highway=primary und construction=yes) - Nur ein Tag nötig - In dem einen Tag wird alles deutlich. Nachteil: Den einzigen den ich sehe, es wird bisher nicht unterstützt :) Das Problem sollte aber denke ich lösbar sein (ersetzung der Regeln von highway=construction mit construction:highway=*) Einfach mal drüber nachdenken, evtl. ist es ja ein hilfreicher Lösungsansatz. Ich empfinde es momentan als ziemlich praktisch und logisch, aber vielleicht übersehe ich auch gerade Nachteile. Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Hi Claudius. Claudius Henrichs wrote: @Gerrit: Hast du dich da schon mal mit den international an diesem Thema interessierten OSMlern in der Traffic/Transit-Liste kurzgeschlossen? Ich meine es gibt da ja inzwischen Bestrebungen zu international stimmigen Symbolen und Kartendarstellungen. Vielleicht könnte das also gleich richtig umgesetzt werden. Ja, dort schreib ich auch. Aber dort kamen auch nur 1-2 joa, find ich ganz sinnvoll antworten und wenig handfestes. Diese Haltestellengeschichte ist mir schon unangenehm an OSM aufgefallen, seit ich vor 2 zwei Jahren das erste Mal damit zu tun hatte (habe OSM-Daten benutzt um darauf Busrouting zu machen). und seitdem hat sich nicht viel in der Sache getan. Die Relations für die Routen sind ein immenser Fortschritt, aber die Stop-Problematik besteht weiterhin. Inklusive der Uneinigkeit ob Stops neben oder auf dem Weg getaggt werden sollen. Was das angeht hab ich mich selbst immer mal wieder umentschieden, je nachdem aus welchem Gesichtspunkt ich das betrachtet habe. Aus genau diesem Grund hab ich das beschriebene vorgeschlagen, da es sehr viele von den mir mit dem Status Quo begegneten Problemen lösen würde und (das finde ich ganz wichtig) flexibel, eiinfach und erweiterbar ist. Das ich auf den verschiedenen Listen und Threads praktisch keinen Widerspruch gehört habe, freut mich zwar zum einen, aber da sich auf der anderen Seite auch niemand für die häufiger in diesem Zusammenhang angesprochene Frage wie denn nun die Platform zu taggen sei interessiert, gehe ich eher davon aus, dass insgesamt kein großes Interesse an dem Thema ÖPNV besteht oder zumindest an einer Verbesserung des Status Quo. Daher verspreche ich mir von einer Renderunterstützung dieses Schemas auch a) ein größeres Interesse und b) die Chance Fehler oder Schwachstellen leichter zu ermitteln. Das war jetzt vermutlich viel mehr Information als Du haben wolltest, aber ich hab gerade Zeit. :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Hallo, Zitat von silversurfer silversur...@oleco.net: ich würde amenity=university;hospital machen Verstehen das die Renderer? Ein Krankenhaus ist doch so wichtig, dass es schon jetzt richtig angezeigt werden sollte. und in Deinem Spezialfall noch ergänzen operator=Rhön-Klinikum AG. Gute Idee. Was das MPI angeht, habe ich ein proposal amenity=research_institution eingereicht (http://wiki.openstreetmap.org/wiki/Proposed_features/research_institution). Wurde aber zurückgewiesen, weil es im eigentlichen Sinne wohl keine Annehmlichkeit ist (was ich auch bei anderen für etwas fraglich halte). Kann ich auch nachvollziehen. Im Moment tendiere ich zu research_institution=yes. Das beschreibt es sicher gut, ist aber als Tag kaum genutzt, oder? Man könnte hier auch ein operator=Max Planck Gesellschaft dranhängen. - Jutta -- http://www.weisel.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation über Kreisverkehr
Hallo Liste, Wie tagge ich eine Relation über einen Kreisverkehr? 1) Ist der Kreisverkehr komplett ein Teil der Relation? Dann wäre dort ein Bruch der Relation. 2) Nehme ich den Kreisverkehr nicht mit in die Relation auf? Dann wäre dort ein Loch in der Relation. 3) Spalte ich den Kreisverkehr so auf, dass er in die Relation passt, wie man es bei anderen Wegen auch macht? Dann wäre die Relation durchgängig. Schon mal vielen Dank für die Hilfe. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Torsten Leistikow wrote: Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Naja... daß ein Areal mit so ein paar Fußballplätzen oder ein Tennisclub ein sports_centre sein könnte, lasse ich mir ja noch einreden, aber ein Gym? Ich hab mittlerweile einen Thread in talk gefunden, dort wurde auch sports_centre erwähnt und wieder verworfen. Dort war der Clue leisure=fitness_center, das macht wohl den meisten Sinn. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Jutta Weisel schrieb: Hallo, Zitat von silversurfer silversur...@oleco.net: ich würde amenity=university;hospital machen Verstehen das die Renderer? Nein. Und wenn ich wetten müßte, wird das auch nicht so schnell passieren. Im JOSM z.B. würde es die Kartendarstellung wohl langsamer machen. Ein Krankenhaus ist doch so wichtig, dass es schon jetzt richtig angezeigt werden sollte. Sehe ich auch so. Die Hauptanwendung ist doch eher das Hospital. Ein Mitarbeiter könnte natürlich auch argumentieren: Das ist hier eine Universität, die Patienten behandeln wir nur nebenbei ;-) Was das MPI angeht, habe ich ein proposal amenity=research_institution eingereicht (http://wiki.openstreetmap.org/wiki/Proposed_features/research_institution). Wurde aber zurückgewiesen, weil es im eigentlichen Sinne wohl keine Annehmlichkeit ist (was ich auch bei anderen für etwas fraglich halte). Kann ich auch nachvollziehen. Im Moment tendiere ich zu research_institution=yes. Das beschreibt es sicher gut, ist aber als Tag kaum genutzt, oder? Bislang genau drei mal. Daneben gibt es dann noch: institute research research_centre ... und vielleicht noch andere. Trag es halt erstmal so ein wie du meinst, wenn sich da eine erkennbare Häufung gebildet hat kann man immer noch aufräumen. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Kann man die Nummern nicht einfach wie bei Google anzeigen? Müssen wir es unbedingt ANDERS machen? Ich finde, dass einfach die Zahl ausreicht, evtl. nicht schwarz sondern grau. Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Jutta Weisel schrieb: Ich habe gesehen, Deine Gebäude sind mit amnity=university und building=yes getaggt. So habe ich es auch gemacht, sehe aber in den Mapnik-Rules, dass die Polygon-Rules zu building=yes die zu anmity=university überschreiben. Frage: sind die Rules falsch oder die Tag-Kombination? Falsch ist so ein hartes Wort ;-) Die Angewohnheit überall ein building=yes dranzumachen ist ja im Gros der Mapperschaft noch recht neu (wie Gebäude überhaupt als Flächen einzuzeichnen), daher sind die Renderer da auch noch nicht sooo fortschrittlich. Das building=yes macht aus meiner Sicht aber durchaus Sinn. Beim Josm greift die Regel für building=yes nur mit niedriger Priorität, ein amenity=university greift eher und wird entsprechend dargestellt. Die anderen Renderer sollten dementsprechend angepaßt werden. Bitte nimm dir die Zeit und trag solche Sachen doch als Bug ein - sonst wird es ja nie besser ;-) Gleiches gilt übrigens auch für amenity=hospital und buildung=yes. Damit kommt auch der Osmarender nich zurande, er bringt den Namen ein zweites Mal über dem roten Kreuz. Auch da ist halt noch Optimierungspotential. Gruß, ULFL P.S.: Bitte lass doch etwas mehr Sorgfalt bei der key/value Schreibweise walten! In deiner Mail waren mehrere Tippfehler drin, z.B. buildung=yes - damit lernen Neulinge die Sachen doch nie richtig zu schreiben ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Am Samstag 24 Januar 2009 schrieb Sebastian Hohmann: Fabian -Patzi- Patzke schrieb: Guenther Meyer schrieb: wie waers denn mit folgendem schema (aehnlich dem, was schon vor ein paar monaten diskutiert wurde): access:gruppe[optionale einschraenkungen] = art des verkehrs beispiele: das klassische weisse schild mit rotem rand (zeichen 250): access:vehicle = no [...] analog fuer andere kombinationen... meinungen? jo :), hab ich auch im talk auf der wiki seite geschrieben. Ich halte es für sinnvoll bei neuen tags ein namespace mit einzuführen, hier halt access:. Das die alten access tags auch in diesem Schema besser aufgehoben wären steht dabei außer frage. Man wüsste halt bei access:hazmat=* gleich worum es ungefähr geht im gegensatz zu nur hazmat=*. Grüße, Fabian Da hab ich auch nichts dagegen, nur geht es bei dem Proposal lediglich um neue Schlüssel und Werte. Ich finde es nicht sinnvoll eine neues Schema nur für einige Tags einzuführen, das würde nur Verwirrung stiften. Schließlich gliedern die sich alle in die access-Gruppen ein und sollten auch einheitlich behandelt werden. mein weg geht in die richtung, die gesamte access-gruppe zu vereinheitlichen. alles andere ist nur rumgebastel, finde ich... Meiner Meinung nach wäre es besser ein extra Proposal dafür zu erstellen (oder gibt es das schon?), wo man die Möglichkeit hat das neue Schema zu disktutieren. es gab vor einiger zeit eine diskussion dazu auf der liste, aber soweit ich weiss, hat niemand daraus ein proposal gemacht. Wer es will kann es ja sowieso schon einsetzen, es gibt schließlich keine Beschränkungen was die Tags angeht. Wenn genug Leute es für sinnvoll halten, setzt es sich auch durch. Man muss nur darauf hinweisen und das geht am besten über ein Proposal (für das natürlich auch Werbung gemacht wird). richtig. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten in JOSM einblenden
Hallo, kann ich eigenes Bildmaterial in JOSM einblenden lassen? Ich bin Orts-Chronist in meinen Dorf und wir haben vor einigen Jahren selbst eine Karte für eine Publikation erstellt, eigene Rechte liegen also vor. Nun würde ich ja gerne das selbst nutzen. Außerdem habe ich einiges Material älter als 70 Jahre, also frei von Urheberrechten. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation über Kreisverkehr
Fabian -Patzi- Patzke schrieb: Ich habe, wenn es bei mir vorkam, immer den ganzen Kreisverkehr reingemacht, schadet finde ich nicht. Das denke ich auch. Ich finde, dass eine Relation, z.B. eine Route, auch immer den gesamten Kreisverkehr enthalten sollte. So hab ich es halt gemacht, siehe z.B. http://www.öpnvkarte.de/?lat=51.92595lon=10.43604zoom=17 Da geht die Busroute auch durch den ganzen Kreisel. Die meisten Routen sind ja auch nicht gerichtet. Insofern haette man, je nach Richtung, sowieso einmal die eine und einmal die andere Seite vom Kreisverkehr mit drin. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
On Sat, 24 Jan 2009 16:42:59 +0100, Jutta Weisel ju...@weisel.de wrote: Verstehen das die Renderer? Ein Krankenhaus ist doch so wichtig, dass es schon jetzt richtig angezeigt werden sollte. Jetzt gibt es ja auch ein Proposal für healthcare (http://wiki.openstreetmap.org/wiki/Proposed_features/healthcare). Man darf also gespannt sein. Grischa ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten in JOSM einblenden
Am 24.01.2009 17:56, Arne Bischoff: kann ich eigenes Bildmaterial in JOSM einblenden lassen? Ich bin Orts-Chronist in meinen Dorf und wir haben vor einigen Jahren selbst eine Karte für eine Publikation erstellt, eigene Rechte liegen also vor. Nun würde ich ja gerne das selbst nutzen. Außerdem habe ich einiges Material älter als 70 Jahre, also frei von Urheberrechten. 1.) Mithilfe des Metacarta Mac Rectifiers referenzierst du dein Bildmaterial mit Geokoordinaten: http://labs.metacarta.com/rectifier/ 2.) In JOSM verwendest du dann das Plugin wmsplugin und im dann angezeigten Menü WMS - Berichtiges Bild. Dort gibst du die Nummer deines bei obiger Seite hochgeladenen Bildes an. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Hallo Gerrit, 1. Farbgebung der Linien Momentan finde ich sind die dunklen Tram/UBahn-Linien zu prominent, vor allem gegenüber den kaum sichtbaren hellen Zugstrecken. Zudem sind Ubahn und tram kaum zu unterscheiden, Verkehren aber in einem ähnlichen Kontext. Mein Vorschlag: - light_rail werden blau (wie jetzt tram) mit dünner Linie. - train werden grün (wie jetzt light_rail) mit dicker Linie, evtl etwas dunkler. - bus bekommt eine dünne rote Linie - tram wird orange (etwas dunkler als jetzt train) und bekommt eine dickere Linie als Bus. - subway wird violett (wie jetzt ferry) und eine dünne Linie. - ferry könnte das dunkle blau der jetzigen subway bekommen. Mit meinem Farbschema bin ich momentan auch nicht ganz zufrieden, allerdings hadere ich auch damit alles komplett über den Haufen zu werfen. Dein Schema überzeugt mich ehrlich gesagt auch nicht vollständig. 1. weil das Grün der Züge in der Übersicht in den Grünflächen verschwindet. 2. weil Blau für Fähren auf dem Wasser auch nicht ideal ist. Mein Ziel wäre mittelfristig auch die Farben nicht von den Tags abhängig zu machen, da die fast nach belieben verwendet werden, sondern von den Haltestellenabständen. 2. Farbgebung der Haltestellen == Analog zu obigem Farbschema könnte man auch bei den Haltepunkten verdeutlichen, welche Fahrzeugart wo hält. Nicht in ein Netz eingebundene Halte sind wie jetzt weiß. Stationen wo ein Bus hält bekommen einen relativ kleinen roten Punkt. Solche mit Tram-Halt einen orangenen Kreis außen rum. (subway einen violetten Punkt) Analog mit train und light_rail. Auf diese Weise kann man leicht sehen, welche ÖPNV-Art wo hält. Das wäre natürlich sehr gut, ich habe momentan nur leider nicht die Haltestellen der Relationen in der Datenbank 3. Umgang mit Haltestellen-Relationen = Vielleicht hast Du mitbekommen, das ich vor kurzem einen Vorschlag gemacht habe, wie man Haltestellen als Relation möglichst vollständig abbilden kann. Hintergrund: Momentan gibt es teilweise 4 oder mehr Haltepunkte für eine Station, entsprechend hässlich sieht es auf der Karte aus, wenn der Stationsname 4 mal auftaucht. Teilweise wird aber auch nur ein einziger Node gemappt für manchmal weit auseinanderliegende Haltepunkte. Zusammenfassung meines Vorschlages: Es gibt mindestens einen Halt mit highway=bus_stop, bzw. railway=station/halt. Dieser liegt AUF dem entsprechenden Weg. Dieser Punkt wird entsprechend in die Route-Relationen aufgenommen. Zudem werden die Orte des Haltestellenschildes/Wartehäusschens/Bahnsteigs NEBEN den Fahrweg an ihrer tatsächliche Position markiert und mit highway=platform markiert (inzwischen tendiere ich allerdings immer mehr zu amenity=platform). Dies alles wird in eine Relation type=site;site=stop_area gepackt und mit Namen, Operator etc versehen. Dieses Schema gilt für alle Systeme (bus,tram,train,...). Wenn das so durchgehend umgesetzt würde wäre das für die Karte natürlich schön. Meine Idee wäre einfach die Haltestellen in einem gewissen Umkreis mit ähnlichem Namen in der Übersicht zusammenzufassen, das würde eine Menge Mapping Arbeit sparen. Auch wenn ich so auf die schnelle nichts umsetzen kann, danke für die Anregungen. Gruß, Melchior ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation über Kreisverkehr
Torsten Leistikow schrieb: Fabian -Patzi- Patzke schrieb: Ich habe, wenn es bei mir vorkam, immer den ganzen Kreisverkehr reingemacht, schadet finde ich nicht. Das denke ich auch. Ich finde, dass eine Relation, z.B. eine Route, auch immer den gesamten Kreisverkehr enthalten sollte. So hab ich es halt gemacht, siehe z.B. http://www.öpnvkarte.de/?lat=51.92595lon=10.43604zoom=17 Da geht die Busroute auch durch den ganzen Kreisel. Die meisten Routen sind ja auch nicht gerichtet. Insofern haette man, je nach Richtung, sowieso einmal die eine und einmal die andere Seite vom Kreisverkehr mit drin. Gruss Torsten Nur zeigt dann der Relation-Check unter betaplace.emaitie.de Brüche in der Relation. Deshalb war ich mir nicht mehr ganz sicher, Gruß, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
Florian Lohoff schrieb: Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. nein... das fand ich überhaupt nicht ok. ich hab mir so viel mühe gegeben mit den Hausnummern, da möchte ich doch nicht, dass jede 2. von einem symbol überdeckt wird. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. das wäre die beste Lösung. dann muss man dieses Overlay aber auch entdecken und anschalten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
On Sat, 24 Jan 2009 19:11:38 +0100, Jutta Weisel ju...@weisel.de wrote: Ich habe mir gerade überlegt, dass das vielleicht doch Sinn macht, nämlich wenn man den Campus mit amenity=university oder hospital taggt und die Gebäude auf dem Campus zusätzlich mit building=yes. Das wird zumindest auch in Berlin mit HU, TU und FU so gemacht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation über Kreisverkehr
Peter Vitt pe...@dotnetphen.com writes: 3) Spalte ich den Kreisverkehr so auf, dass er in die Relation passt, wie man es bei anderen Wegen auch macht? Dann wäre die Relation durchgängig. Ja, aufsplitten. Und den kreisverkehr selbst auch wieder in eine relation packen. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Am 24. Januar 2009 17:12 schrieb Andreas Labres l...@lab.at: Torsten Leistikow wrote: Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Naja... daß ein Areal mit so ein paar Fußballplätzen oder ein Tennisclub ein sports_centre sein könnte, lasse ich mir ja noch einreden, aber ein Gym? Ich hab mittlerweile einen Thread in talk gefunden, dort wurde auch sports_centre erwähnt und wieder verworfen. Dort war der Clue leisure=fitness_center, das macht wohl den meisten Sinn. Servus, Andreas aber lieber schön britisch fitness_centre Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Jutta Weisel schrieb: Ich habe mir gerade überlegt, dass das vielleicht doch Sinn macht, nämlich wenn man den Campus mit amenity=university oder hospital taggt und die Gebäude auf dem Campus zusätzlich mit building=yes. Das passt allerdings nicht zu den JOSM-Vorlagen, da wird amenity=university unter Gebäude angeboten. Die JOSM Presets sind ja auch eher für die einfachen Fälle gedacht ;-) Übrigens: Wenn die einzelnen (größeren) Häuser Namen oder Nummern haben (was ja meist der Fall ist), die auch ruhig eintragen. Mapnik zeigt das dann ab Z16 recht schön an: http://openstreetmap.org/?lat=49.41848lon=11.11841zoom=16layers=B000FTF Wenn ich da irgendwo hinwill, ist das ja durchaus informativ wohin ich eigentlich genau muß ;-) Bitte nimm dir die Zeit und trag solche Sachen doch als Bug ein - sonst wird es ja nie besser ;-) Wie geht das? Oder meinst Du http://wiki.openstreetmap.org/wiki/OpenStreetBugs? Nein, ich meine die jeweiligen Bugtracker (für Slippy Map, Mapnik, JOSM, ...), die du unter: http://wiki.openstreetmap.org/wiki/Develop in der Spalte Bugs findest. P.S.: Bitte lass doch etwas mehr Sorgfalt bei der key/value Schreibweise walten! In deiner Mail waren mehrere Tippfehler drin, z.B. buildung=yes - damit lernen Neulinge die Sachen doch nie richtig zu schreiben ;-) Da hast Du recht, ich gelobe Besserung! Sehr schön! Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Martin Simon grenzde...@gmail.com [Sat, Jan 24, 2009 at 11:02:34AM CET]: [...] construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zurückgebaut trifft die Sache einfach besser. Nicht zu vergessen den Zustand in musealen Zustand versetzt. So etwas vermisse ich schmerzlich. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Ein Atomkraftwerk in Bau ist eine Trasse? Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Es gab bei den jüngeren Ansätzen für ein solches Modell zweifache Opposition. Die einen hassten den Ausdruck life_cycle so sehr, dass sie allein aufgrund dieses Wortes entschlossen waren, das Konzept abzulehnen. Die anderen folgten einer ähnlichen Argumentation wie Heiko. Wenn man bei jedem Element erst nachschauen muss, ob es noch in Betrieb ist, so wird der Code-Wust größer. Den ersten Einwand kann ich nicht ernstnehmen, würde aber um den Wortlaut nicht streiten wollen. Hauptsache, das Konzept existiert, da kann sich die Gegenseite gerne das Wort aussuchen, von mir aus auch grungelborz. Der zweite Einwand ist ernst zu nehmen. Könnte man den Leuten, die hier Furcht hegen, soweit entgegenkommen, dass man dreimal wöchentlich ein frisches gefiltertes .osm bereitstellt, aus dem alle highways herausgefiltert sind, die grungelborz != active sind? Nur so eine Idee. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
2009/1/24 Josias speak...@j-po.de Florian Lohoff schrieb: Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. nein... das fand ich überhaupt nicht ok. ich hab mir so viel mühe gegeben mit den Hausnummern, da möchte ich doch nicht, dass jede 2. von einem symbol überdeckt wird. ich wäre auch eher dafür, die Nr. unten zu rendern, also über der Karte, unter Icons, unter Text. Wenn ein paar auf der allgemeinen gerenderten Karte dann verdeckt werden, ist das doch nicht so tragisch, wichtig ist, dass sie drin sind und gefunden werden. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. das wäre die beste Lösung. dann muss man dieses Overlay aber auch entdecken und anschalten. ja, in der Karte finde ich sie schon an sich sinnvoll, allerdings (das schreibe ich schon regelmäßig seit es sie gibt) würde es ausreichen, wenn sie als kleine schwarze Zahl ohne Hintergrund oder Umrandung dargestellt würden, da stören sie dann auch die empfindsameren Zeitgenossen nicht mehr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
BroadwayLamb wrote: ...und noch ein Mecker ;) Da ich mich grade ein wenig in die Erfassung von Hausnummern verbissen habe, irritiert mich mal wieder die Darstellung derselben. Mancherorts sieht man vor lauter Hausnummerklecksen nichts anderes mehr (Altstadt MG z.B. - sorry, hab grad keinen Link). War da nicht mal eine Änderung geplant? Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. IIRC ist das prominente Rendering eingeführt worden, nachdem das Karlsruhe-Schema entwickelt wurde, um die Fortschritte hier gleich ganz drastisch sichtbar zu machen. Hintergedanke war wohl, wenn das Hausnummern-mappen einmal etabliert ist, die Sichtbarkeit wieder zurückzufahren. Im Mailinglisten-Archiv müsst man das nachlesen können. lg roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] riverbank und wildbach
2009/1/23 Garry garr...@gmx.de Hermann Schwärzler schrieb: soll ich die hochwasser-ufer-linie (also meist den schutzdamm) als riverbank eintragen? oder wie macht ihr das? Riverbank wäre glaube ich ungünstig.. Vor längere Zeit waren hier mal Wadis im Gespräch - vielleicht hilft Dir das Stichwort weiter... Wadi scheint mir recht speziell zu sein (Wikipedia: Wadi= bezeichnet einen zeitweilig austrocknenden Flusslauf in einem Trockentalhttp://de.wikipedia.org/wiki/Trockentalin den Wüstengebieten http://de.wikipedia.org/wiki/W%C3%BCste Nordafrikashttp://de.wikipedia.org/wiki/Nordafrika, Vorderasiens http://de.wikipedia.org/wiki/Vorderasien und teilweise Spaniens http://de.wikipedia.org/wiki/Spanien. Im Südwesten Afrikas werden solche Trockenflüsse Riviere http://de.wikipedia.org/wiki/Rivier genannt, in Australien Creeks http://de.wikipedia.org/wiki/Creek, in Süd- und Teilen Nordamerikas Arroyos und auf Spanisch Barranco. Riverbank ist prinzipiell nicht falsch für die äußere Grenze, weil dort ja das Flussufer ist, auch wenn der Fluss überwiegend nicht bis dort hinkommt, dennoch wird man das Flussbett nicht wie die übrige Umgebung klassifizieren wollen. Wenn man es genau machen will, wird man sich wohl was spezielles Ausdenken müssen (ich würde die äußere Grenze als normal mappen und die innere, wenn der Fluss wenig Wasser hat, als Spezialfall, weil man wohl das gesamte maximal genutzte Areal als Flussbett bezeichnen wird). Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Karte: Main in Frankfurt ausgetro cknet
Hi Markus, Markus Stürmer schrieb: Auf [1] steht: Do not add natural=water to the way since this is intended for areas forming lakes. Aha. Na dann eben nicht. Was ist ein Teich? Oder sonst eine Wasserfläche, die kein See ist? (Altarme z.B. von Flüssen, die sind eigentlich ja keine Flüsse mehr oder?) natural=water tags entfernt. Das die Namen an den Riverbanks auch entfernt wurden hat den Grund, dass somit durch die Linie (waterway=river) und die Fläche Namen gerendert wurden, wobei die der Fläche öfter auch außerhalb des Mains lagen. Ich gehe immer noch von dem Grundsatz aus, dass wir nicht für den Renderer Mappen sondern für die Karte, wenn die Renderer die Namen außerhalb der Karte erzeugen, dann ist nicht die Karteninfornation falsch, sondern der Renderer muß korrigiert werde. Mein Renderer heißt mkgmap und der hat den Namen imemr auf der Fläche gehabt. Die Inseln/Staustufen habe ich in Relationen gepackt, da diese von Mapnik und Osmarender unterstützt werden und normalerweise keine Probleme mehr bereiten (ab und an hat Mapnik noch mit der Richtung der Wege Probleme). Warum Relationen einführen wo es nicht notwendig ist. Ich wundere mich nur, dass Du das geändert hast. Was ist besser an der Relation als an der vorherigen Methode? Wie auf [2] zu entnehmen und auch von Frederik mehrfach auf der Mailingliste und anderweitig angemerkt ist es nicht nötig den inneren Weg einer Multipolygon-Relation mit Tags zu versehen. Daher haben sie meist auch keinen, wenn ich das anfasse. Sollte auf den Inseln etwas anderes sein, als nur kein Wasser, dann kann man Tags vergeben, z.B. natural=scrub ... Von mir aus kann man das für neue Sachen ja verwenden, auf Teufel komm raus alte funktionierende Sachen zu ändern, dafür haben wir eigentlich noch genügend Anderes zu tun, auch in Frankfurt. Von mir aus kann es ja so bleiben, ich werde mich persönlich nicht der Relationitis anschließen, und in der Garminkarte siehts halt im Moment doof aus, da ich Inseln eben nur dann aus dem Wasser heben kann, wenn da Land getaggt ist. (Oder die Insel aus dem Wasser ausgespart ist) -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Am Samstag 24 Januar 2009 14:48:22 schrieb Karl Eichwalder: Marc Schütz schue...@gmx.net writes: Ich finde, im jetzigen Zustand der Unordnung Rückwärtskompatibilität einzuführen äußerst kontraproduktiv. Ich sehe das anders. Viele städte in D sind straßenmäßig fertig und in vielen regionen sind auch schon alle hauptverbindungen drin. Da sollte man sich bemühen, nicht noch mehr chaos anzurichten. Ich habe damit das bereits bestehende Chaos im Tagging gemeint. Es ist ganz gut, in der Anfangsphase freies Tagging zu betreiben, weil sich erst noch herausstellen muss, was man eigentlich alles in die Karte aufnehmen will, und wie man das am besten darstellt. Aber jetzt auf Kompatibilität zu pochen, führt nur dazu, dass die vielen Fehler, die zweifellos gemacht worden sind, für immer festzementiert werden. Man könnte die durch Änderungen am Taggingschema entstehenden Unstimmigkeiten sogar als Ansporn/Druckmittel ansehen, beim nächsten Tag, den man erfindet, lieber vorher nachzudenken, wie man ihn so gestaltet, dass er sich mit zukünftigen Erweiterungen gut verträgt. Irgendwann sollte man dann hergehen und zumindest einen Teilbereich der Tags als festen Standard definieren, natürlich unter Berücksichtigung der _Vorwärts_kompatibilität, alle Benutzer (Mapper und Datenverwerter) eindringlich dazu auffordern sich dranzuhalten, und vielleicht auch per Bot die Daten daran anpassen. Erst dann macht Rückwärtskompatibilität richtig Sinn, weil es vorher ja noch nicht mal einen Standard gibt, zu dem kompatibel sein kann. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] riverbank und wildbach
Martin Koppenhoefer schrieb: Riverbank ist prinzipiell nicht falsch für die äußere Grenze, weil dort ja das Flussufer ist, auch wenn der Fluss überwiegend nicht bis dort hinkommt, dennoch wird man das Flussbett nicht wie die übrige Umgebung klassifizieren wollen. Wenn man es genau machen will, wird man sich wohl was spezielles Ausdenken müssen (ich würde die äußere Grenze als normal mappen und die innere, wenn der Fluss wenig Wasser hat, als Spezialfall, weil man wohl das gesamte maximal genutzte Areal als Flussbett bezeichnen wird). Ich weiss ja nicht wie das vor Ort aussieht, wenn da kein Wasser ist, aber das waere fuer mich das Entscheidende. Beim Wattenmeer habe ich z.B. kein Problem damit, dass man das als Wasserflaeche ansieht, die zeitweise trocken liegt. Wenn es im Ueberschwemmungsbereich aber normalen Pflanzenbewuchs (Gras, Baeume) gibt, dann scheint mir da riverbank nicht angemessen. Nur weil eine Wiese mal ueberschwemmt werden kann, bleibt sie doch eine Wiese und wird nicht pauschal zum Fluass. Da wuerde ich dann eher bei natural=wetland mal gucken, ob man da nicht was passendes finden (oder eventuell hinzufuegen) kann. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osmrender.pl version 2 veröffentlich t
hi, obwohl das programm sicher nie fertig wird (aber es soll sich ja auch jeder anpassen), habe ich mal eine zweite version veröffentlicht. sie erstellt nun auch - SVG dateien - straßennamen siehe beispiel hier: http://www.gary68.de/osm/hof.svg viel spaß damit download von meiner wiki seite http://wiki.openstreetmap.org/wiki/User:Gary68 doku hier http://wiki.openstreetmap.org/wiki/Osmrender.pl http://wiki.openstreetmap.org/wiki/Osmgraph.pm gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Christian Koerner schrieb: Garry wrote: Ach ja - bei den von mir erfassten Daten verhindere ich die Router-Fehlfunktion zuverlässig in dem ich die in Bau/Plannung befindliche Strassen nicht an öffentliche Strassennetz anschliesse (kleine Unterbrechungen der Ways) - leider wird das von einigen übereifrigen Taggern immer wieder repariert so dass es dann zu dem Router-Problem kommen kann. Lass die Straszen doch verbunden und setzt einfach ein access=no. Nur für das Übergangsstück oder die gesamte Trasse? Letzteres wäre etwas mühsam da es ja auch bei Inbetriebnahme wieder vollständig entfernt werden muss- mit der Unterbrechung kann ich leicht sicherstellen dass auch sehr einfache Router nich auf die Baustelle routen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Frederik Fischer fe...@studio-24.net wrote: http://wiki.openstreetmap.org/index.php/Cobra Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Etwas verwunderlich wo doch drueber steht, Cobra ziele vorrangig auf Windoof... ;-) Jedenfalls kann weder Vista noch mein cygwin darauf da was mit anfangen, also bleibt's Praesent erstmal unausgepackt... ;-) Dieses Cobra meinte ich. Mit Offset meine ich eine Projektion des Pfades um einen bestimmten Betrag nach rechts oder links. Eine einfache Translation w?rde ja, wie von dir erw?hnt, nicht ausreichen. ( http://osm.studio-24.net/images/cobra/path_offset.png ) Ja, sowas waere noetig fuer einseitiges... ( http://osm.studio-24.net/images/cobra/dev08091603.jpg ) Die DIskussionsseite klingt so, als waere das getrickst, oder verstehe ich da was falsch? ABer vermutlich meinst Du das, was auf der Cobra-Seite mit virtual ways bezeichnet wurde und das mit dem dy=0.4? Macht Cobra aus dem .osm dann trotzdem gueltiges SVG? In der Tat waere das dann ein Zuruecklassen der XSLT-Entwicklungslinie, die dann nicht mehr mit der orp-Linie kompatibel waere... Muessen die Osmarender-Erfinder entscheiden, ob das im Sinne Osmarenders ist... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
