Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: You both are right, old is the wrong word for what I wanted to say. I do not want to replace or deprecate highway=bus_stop. Because English is not my first language, I catched up to consult my dictionary and I think traditional or conventional would be the better word, expressing what I wanted to say. established would be a better term ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
I'm one of the people who would like to add data about Public Tranportation. Since nobody likes to have to enter the same data several times, I can understand the need for a 'definitive' way to map PT in such a way that all downstream users (map rendereres, routers, etc) have the information they need to work with. Apparently the system that you want to call established does not completely cater for that, so people come up with improvements. I like the proposal, the only thing I don't like about it is the massive duplication of information in the route relations, which will make it harder to maintain them in the long run. But I see why we would do it that way. Maybe I'll come up with a proposal for 'proto-relations' made up of other 'routepart'-relations some time. Those could get converted to the massively duplicated relations automatically then. Cheers, Jo 2010/12/13 Richard Mann richard.mann.westoxf...@gmail.com On Mon, Dec 13, 2010 at 8:54 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: You both are right, old is the wrong word for what I wanted to say. I do not want to replace or deprecate highway=bus_stop. Because English is not my first language, I catched up to consult my dictionary and I think traditional or conventional would be the better word, expressing what I wanted to say. established would be a better term ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 11:52 AM, Jo wrote: I like the proposal, the only thing I don't like about it is the massive duplication of information in the route relations, which will make it harder to maintain them in the long run. But I see why we would do it that way. Maybe I'll come up with a proposal for 'proto-relations' made up of other 'routepart'-relations some time. Those could get converted to the massively duplicated relations automatically then. When I understand correct you mean the same as Marl brought up on the talk page under Shared Route Segments: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Public_Transport#Shared_Route_Segments Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
I think I may have figured out what it is that the established tags can't do. If you've got a railway=tram with a series of nice neat (and well-established) railway=tram_stop nodes then you can only make that railway=tram_stop node a member of a route relation once. The oxomoa conclusion was to have single-direction route relations. But this doesn't work well when you have lines that loop at the ends (fairly common with bus services), because the two relations overlap (you have to make certain nodes members in both relations, and that starts crossing a complexity/maintainability threshold). I think what we're edging towards is that expressing a tram stop as a single node isn't really enough. I think the open question is how tram stop pole nodes should be tagged, whether that affects highway=bus_stop, and how you deal with joint bus and tram stops. My suggestion: 1) highway=bus_stop - nodes to mark bus stop poles and to be members of bus relations (can also be used for tram relations) 2) highway=tram_stop - nodes to mark tram stop poles and to be members of tram relations (can also be used for bus relations). Renderers may prefer not to render these (there will generally be a railway=tram_stop node to use instead). There are only 13 of these in the world according to taginfo, so adoption of this tag for this purpose is unlikely to annoy anyone too much. 3) railway=tram_stop - nodes to mark the centre of the tram stop area, in the absence of a stop area relation. Mostly for rendering/labelling purposes. Can be used as a member of uni-directional relations, if setting up highway=tram_stop nodes is viewed as too complicated. Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 01:12 PM, Richard Mann wrote: But this doesn't work well when you have lines that loop at the ends (fairly common with bus services), because the two relations overlap (you have to make certain nodes members in both relations, and that starts crossing a complexity/maintainability threshold). I see the problem with looping lines and I know several practical examples. Even hafas sometimes can not handle this correctly and if then this is usually solved that one stop is defined as the terminal stop. The stops before belong to the route to the terminal stop, the others to the route back. So in theory you have to change the bus at the terminal stop, in practice this is not the case. I think what we're edging towards is that expressing a tram stop as a single node isn't really enough. I think the open question is how tram stop pole nodes should be tagged, whether that affects highway=bus_stop, and how you deal with joint bus and tram stops. I support that one node for a 40m long tram stop isn't really enough. My suggestion: 1) highway=bus_stop - nodes to mark bus stop poles and to be members of bus relations (can also be used for tram relations) 2) highway=tram_stop - nodes to mark tram stop poles and to be members of tram relations (can also be used for bus relations). Renderers may prefer not to render these (there will generally be a railway=tram_stop node to use instead). There are only 13 of these in the world according to taginfo, so adoption of this tag for this purpose is unlikely to annoy anyone too much. 3) railway=tram_stop - nodes to mark the centre of the tram stop area, in the absence of a stop area relation. Mostly for rendering/labelling purposes. Can be used as a member of uni-directional relations, if setting up highway=tram_stop nodes is viewed as too complicated. This is constructive. Thanks for that. May I ask you some questions about that? railway=tram_stop and railway=halt are mainly used for the stop position of a tram/train. highway=bus_stop is the representation of the pole (current schema). Adding highway=tram_stop as the representation of the tram pole eliminates the inconsistency between railway=tram_stop and highway=bus_stop. What do you suggest for trains? Here in Switzerland we have up to 470m long trains (German ICE), so we have up to 470m long platforms with often two or more poles (or displays as a replacement) per platform. Does it make sense to map all poles/displays and to add them to the relation? Doesn't it make more sense to replace the pole(s)/display(s) with the platform for relation data to simplify things? What do you suggest as the stop position for buses (as counterpart of railway=tram_stop and railway=halt)? Or would you leave this completely away? Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Station micromapping ?
Hello transit mappers, I am interested in station micro maps with details such as stairways, levels, corridors, ticketing machines, multilevel maps, platforms, lifts... My ultimate goal is to provide information for pedestrian and/or people with specific needs with info about the route from their train to the station entrance or to a specific connexion. Does anybody have some good examples from which I could learn ? or some appropriate resources/tutorial ? Examples I've found are : - http://www.openstreetmap.org/?lat=48.755206lon=1.943722zoom=18layers=M - http://www.openstreetmap.org/?lat=48.787432lon=2.044487zoom=18layers=M - http://www.openstreetmap.org/?lat=48.86867lon=2.34126zoom=18layers=M My interest is further explained (in french) here : http://transid.blogspot.com/2010/11/plans-des-gares-de-france-sur-osm.html Yann ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/13/2010 06:26 PM, Albin Michlmayr wrote: Till now I solved this by defining one stop in the loop as terminus. This lines then take different routes for each direction. Therefore I found the solution with single-direction route relations quite suitable. I don't know if this is the best solution for openstreetmap but I defenately think that there ist missing something in the established scheme. I agree, I do it equal. The forward or backward role of a way in the relation is in my opinion useless, because it is not clear if it refers to the direction of the way or the route. Currently it is used in both senses. I agree to this too. I think what we're edging towards is that expressing a tram stop as a single node isn't really enough. I think the open question is how tram stop pole nodes should be tagged, whether that affects highway=bus_stop, and how you deal with joint bus and tram stops. When I first discovered the oxomoa-scheme I thougt that it's quite a good idea to use the new tag public_transport because what's the difference between bus and tram stops - there are enough stops used by both means of transport. After following this discussion here I'm not so shure any more because world wide there are already mapped about 66 bus stops as highway=bus_stop and it's senseless to retag all this stops. On the contrary there are also already mapped about 57000 objects as public_transport=* (23000 nodes as stop_position and 22000 nodes and ways as platform) which of course is much less but also too many to retag all these. Because highway=bus_stop (pole) and railway=tram_stop/halt (stop position) have different meanings the current schema is stamped with an inconsistency. Resolving this inconsistency would require a redefinition of at least one of these tags. As you have written: This does not make sense. I don't know which tags are best to be used at the moment but I'm really interested in a broadly accepted guideline for a more unified taging in the future. The longer I think about it, I think it would make sense to use new and clearly defined tags. But the well known tags highway=bus_stop and railway=tram_stop should not lose the meaning/value. In the new schema it should be defined how they are interpreted. For example: node on the way = stop position; node beside the way = pole/platform. So we do not loose information and the already invested work does not lose the value. Actually in my proposal this is missing. Regards Teddych ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [talk-ph] Bing or own aerial pictures...
This is brilliant, for sure, but it leads me to wonder about the idea of mapping using an automatic camera suspended (and therefore vertical) from a balloon or small aeroplane. So no need to rectify. I've read about some people doing this in France etc, but maybe this is a viable alternative to expensive aerial / satellite photography. And its portable, so its possible to take the plane/balloon to places where its needed and use it there. Thinking ... so we'd need - a model plane with remote control (and someone to fly it) - a GPS to record the altitude, lat and long at any given time. - a camera suspended in a sling which would allow it to be pointing towards gravity (or some way of measuring which angle it was pointing at) - some mechanism for taking photos every five seconds (say) and recording the time of the photo. Can't be too hard to figure out ... I'm guessing 1000 USD? Maybe we could even get a grant from the government for it? Jim Anthony Balico wrote, On Monday, 13 December, 2010 01:38 PM: One word: awesome! On Mon, Dec 13, 2010 at 1:06 PM, Totor totor_...@yahoo.com mailto:totor_...@yahoo.com wrote: Hi all, Just a quick note on the imagery. I still have problems stitching them with Hugin. More details here : http://osm.totor.ph/ I was able to align part of the pictures further, using QGIS. Still not good enough in my opinion, but I won't have time to continue the experiment for the moment. Altough not good for editing, I uploaded the resulting imagery for viewing here : http://osm.totor.ph/SM-Cebu/ Selecting the My TMS main layer allows to zoom to 21! Regards, Totor --- On Sun, 11/28/10, Totor totor_...@yahoo.com mailto:totor_...@yahoo.com wrote: That could be great to add them to gravitystorm. But wait for the final ones. The stitched images I have now are not correctly aligned yet. I hope that will be better after replacing the automatic control points with manual ones. (Now automatic points on tall building distort the ground level, so I try to place all control points on ground level.) --- On Sun, 11/28/10, maning sambale wrote: Very cool experiment! Would you like this added to the philippine images we have in the osm dev server (spot and quickbirds)? Maybe we can request gravitystorm to include this imagery. Or you can serve them yourself via tms. ___ talk-ph mailing list talk-ph@openstreetmap.org mailto: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 -- datalude: information security e: j...@datalude.com Philippines: +63 2 403 1311 / mob: +63 917 849 3939 Hong Kong: +852 6840 6693 w: http://www.datalude.com/ ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] Is this click through agreement compatible with OSM?
On Mon, Dec 13, 2010 at 6:56 PM, Gregory Arenius greg...@arenius.com wrote: I read this as saying that the terms of use, which are there as a hold harmless waiver, don't grant any rights. It specifically states that if the city is claiming copyright on the data it will do so in the file or on the website that the file is accessed from. The file in question has no such claims. Ok, well argued. My understanding is that I am legally entitled to grant that license because the city isn't claiming copyright on the data. Its public domain and as such can be added. I think the current draft of the CTs was changed to accommodate such things. One thing I'm curious about is the terms about indemnifying the City of SF against possible harm resulting from using the data. Let's say hypothetically that some third party uses the data that you incorporated into OSM, crashed their car due to bad data, and hypothetically they could sue someone over it. Now the OSM license disclaims liability (on the part of OSMF?) but does that other idemnification apply? (Actually I'm not sure what I'm asking actually makes sense.) Steve ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Is this click through agreement compatible with OSM?
On Mon, Dec 13, 2010 at 12:08 AM, Steve Bennett stevag...@gmail.com wrote: On Mon, Dec 13, 2010 at 6:56 PM, Gregory Arenius greg...@arenius.com wrote: I read this as saying that the terms of use, which are there as a hold harmless waiver, don't grant any rights. It specifically states that if the city is claiming copyright on the data it will do so in the file or on the website that the file is accessed from. The file in question has no such claims. Ok, well argued. My understanding is that I am legally entitled to grant that license because the city isn't claiming copyright on the data. Its public domain and as such can be added. I think the current draft of the CTs was changed to accommodate such things. One thing I'm curious about is the terms about indemnifying the City of SF against possible harm resulting from using the data. Let's say hypothetically that some third party uses the data that you incorporated into OSM, crashed their car due to bad data, and hypothetically they could sue someone over it. Now the OSM license disclaims liability (on the part of OSMF?) but does that other idemnification apply? (Actually I'm not sure what I'm asking actually makes sense.) I understand your question and it does make sense. I'd think if they used our data under a license that disclaims liability that that would be the end of it but. Cheers, Gregory Arenius ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] CT clarification: third-party sources
On Mon, Dec 13, 2010 at 9:44 AM, Robert Kaiser ka...@kairo.at wrote: Anthony schrieb: It's not clear what the denominator is supposed to be. 2/3 of me are still trying to understand you, the rest are yelling he's crazy! - can you clarify what you mean? It's unclear to me whether a 2/3 majority of active contributors have to vote yes, or merely 2/3 of some unspecified quorum of active contributors. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Cannot download
I get this message from JOSM: Error Header=You have downloaded too much data. Please try again later. I am trying download with my GPS track. I am driving in Paris area. How many can I download ? When do I have to wait for download again ? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cannot download
Have you tried zooming in and downloading a smaller area? You can also try right clicking on the gps track in the layers list on the right hand side and choose 'download along track'. Shaun On 13 Dec 2010, at 09:53, Bre Bru wrote: I get this message from JOSM: Error Header=You have downloaded too much data. Please try again later. I am trying download with my GPS track. I am driving in Paris area. How many can I download ? When do I have to wait for download again ? ___ 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] NOTICE: Scheduled Maintenance - Tuesday Morning
OSM, Please copy this to local lists as appropriate. Tuesday 8:45am (14 December 2010 GMT/UTC+0) the API and editing on www.openstreetmap.org will be unavailable during hardware maintenance. The maintenance is expected to take 1 hour. Technical: Replacing a failed RAID Controller Battery. Regards Grant Part of the OSM Sysadmin Team ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] CT clarification: third-party sources
Anthony schrieb: On Sun, Dec 12, 2010 at 9:20 AM, Francis Daveyfjm...@gmail.com wrote: On 12 December 2010 14:08, Robert Kaiserka...@kairo.at wrote: If 67% is not clear in legalese, then legalese is stupid, IMHO. Let's abolish all legal rules and make contributing fun instead, then. There's no such thing as legalese as I've said before. The CT's don't say 67% they say 2/3, which is completely clear. The phrase at least a 2/3 majority vote has a pretty clear and unambiguous meaning. It's not clear what the denominator is supposed to be. 2/3 of me are still trying to understand you, the rest are yelling he's crazy! - can you clarify what you mean? Robert Kaiser ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Cannot download
Download along track is not downloading. It just goes very fast from 1/20 to 20/20 and gives the error message. Download area does not work also. I tried to zoom in very much. http://www.openstreetmap.org/?lat=48.840292lon=2.271422zoom=18 do not work On Mon, Dec 13, 2010 at 11:24 AM, Shaun McDonald sh...@shaunmcdonald.me.ukwrote: Have you tried zooming in and downloading a smaller area? You can also try right clicking on the gps track in the layers list on the right hand side and choose 'download along track'. Shaun On 13 Dec 2010, at 09:53, Bre Bru wrote: I get this message from JOSM: Error Header=You have downloaded too much data. Please try again later. I am trying download with my GPS track. I am driving in Paris area. How many can I download ? When do I have to wait for download again ? ___ 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] NOTICE: Scheduled Maintenance - Tuesday Morning
On Mon, Dec 13, 2010 at 15:24, Grant Slater openstreet...@firefishy.com wrote: Please copy this to local lists as appropriate. With announcements like these could you please send mail like this to local-conta...@openstreetmap.org in the future. That's what it's for. I only found out about this because someone who had happened to be monitoring talk@openstreetmap.org forwarded this to talk-is, but if it had been sent to local-contacts I and others would have spotted it and forwarded it. Thanks. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning
On 13 December 2010 15:40, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: On Mon, Dec 13, 2010 at 15:24, Grant Slater openstreet...@firefishy.com wrote: Please copy this to local lists as appropriate. With announcements like these could you please send mail like this to local-conta...@openstreetmap.org in the future. That's what it's for. I only found out about this because someone who had happened to be monitoring talk@openstreetmap.org forwarded this to talk-is, but if it had been sent to local-contacts I and others would have spotted it and forwarded it. Yup will do. / Grant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Nanomaps
Hi all - I recently had need of a JavaScript map library that was small, efficient and worked across touch and click devices. I started the nanomaps project to address this need. It's still at a pretty early state, but it supports the following: - OSM tiles - Continuous zoom - Scroll wheel - Touch gestures - Declarative map content - 5KB download I haven't tested on IE or Android yet but supporting them should be relatively easy. There are also some improvements that I need to make to the rendering logic for transitioning between native zoom levels more smoothly and averaging the touch gestures ahead to improve perceived scroll performance on the iphone. I'll be working on some more demos later. Watch the github repo if you'd like to be kept up to date on enhancements. Given that the OSM tiles are the obvious first choice for the maps, I thought some of the people hanging out here might find this project useful. Here's the info: - GitHub: https://github.com/stellaeof/nanomaps - Demo: http://stellaeof.github.com/nanomaps/demo/demo.html - Api Docs: http://stellaeof.github.com/nanomaps/apidocs/ It's explicitly trying not to be a do-everything map library, just something for all of those cases where you need a map and no frills access to put interactive bits on it. Enjoy. - Stella ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Nanomaps
Hi, On 12/14/10 04:04, Stella Laurenzo wrote: I recently had need of a JavaScript map library that was small, efficient and worked across touch and click devices. I started the nanomaps project to address this need. It's still at a pretty early state, but it supports the following: It seems to me that you re-implemented KHTML (khtml.org)? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] geen weekbulletin?
Ha allemaal, Ik zie dat er nog geen weekbulletin is gepubliceerd? Wie gaat dat ff doen? Martijn -- Martijn van Exel Senior Researcher / Software Engineer - Geodan SR President Kennedylaan 1 1079 MB Amsterdam (NL) - Tel: +31 (0)20 - 5711 318 Fax: +31 (0)20 - 5711 333 - E-mail: mart...@geodan.nl Website: www.geodan.nl KvK-nummer: 33 247475 Disclaimer: www.geodan.nl/disclaimer - ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] geen weekbulletin?
Martijn, Is is bijna niets gebeurd in het document, dus er valt ook niet veel te publiceren. Als ik de revisiegeschiedenis bekijk ben ik de enige die de afgelopen week iets in het document heeft geplaatst, maar de tweede helft van de week geen tijd gehad om dingen bij te houden. Werk en privé vragen soms ook tijd... Dus er staan drie items in en na de 7e niets meer. En ik heb trouwens nog geen inlog voor de blog en daar heb ik ook nog geen moeite voor gedaan zeg ik er direct bij (reden: zie alinea hierboven ;-) Gegroet, Frank Op 13 december 2010 12:37 heeft Martijn van Exel mart...@geodan.nl het volgende geschreven: Ha allemaal, Ik zie dat er nog geen weekbulletin is gepubliceerd? Wie gaat dat ff doen? Martijn -- Martijn van Exel Senior Researcher / Software Engineer - Geodan SR President Kennedylaan 1 1079 MB Amsterdam (NL) - Tel: +31 (0)20 - 5711 318 Fax: +31 (0)20 - 5711 333 - E-mail: mart...@geodan.nl Website: www.geodan.nl KvK-nummer: 33 247475 Disclaimer: www.geodan.nl/disclaimer - ___ 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] Fwd: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning
OSM, Dinsdag 14 december om 9:45 zal de API offline zijn voor onderhoud, waardoor er dus o.a. niet bewerkt kan worden. Het onderhoud zal naar verwachting een uur duren. De reden is een kapotte batterij in de RAID controller. Deze vertaling werd U gebracht door Peter Hazenberg. Origineel hieronder. -- Forwarded message -- From: Grant Slater openstreet...@firefishy.com Date: 2010/12/13 Subject: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning To: Talk Openstreetmap t...@openstreetmap.org, annou...@openstreetmap.org OSM, Please copy this to local lists as appropriate. Tuesday 8:45am (14 December 2010 GMT/UTC+0) the API and editing on www.openstreetmap.org will be unavailable during hardware maintenance. The maintenance is expected to take 1 hour. Technical: Replacing a failed RAID Controller Battery. Regards Grant Part of the OSM Sysadmin Team ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] geen weekbulletin?
Ik heb net nog het e.e.a geschreven. Kan iemand dit asap publiceren en/of mij een blog login kado doen? Op 13 december 2010 13:28 heeft Frank Fesevur f...@users.sourceforge.net het volgende geschreven: Martijn, Is is bijna niets gebeurd in het document, dus er valt ook niet veel te publiceren. Als ik de revisiegeschiedenis bekijk ben ik de enige die de afgelopen week iets in het document heeft geplaatst, maar de tweede helft van de week geen tijd gehad om dingen bij te houden. Werk en privé vragen soms ook tijd... Dus er staan drie items in en na de 7e niets meer. En ik heb trouwens nog geen inlog voor de blog en daar heb ik ook nog geen moeite voor gedaan zeg ik er direct bij (reden: zie alinea hierboven ;-) Gegroet, Frank Op 13 december 2010 12:37 heeft Martijn van Exel mart...@geodan.nl het volgende geschreven: Ha allemaal, Ik zie dat er nog geen weekbulletin is gepubliceerd? Wie gaat dat ff doen? Martijn -- Martijn van Exel Senior Researcher / Software Engineer - Geodan SR President Kennedylaan 1 1079 MB Amsterdam (NL) - Tel: +31 (0)20 - 5711 318 Fax: +31 (0)20 - 5711 333 - E-mail: mart...@geodan.nl Website: www.geodan.nl KvK-nummer: 33 247475 Disclaimer: www.geodan.nl/disclaimer - ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] geen weekbulletin?
ter info: de desbetreffende accounts zijn aangemaakt Groeten Rob Op 13 december 2010 17:06 heeft Peter pe...@haas-en-berg.nl het volgende geschreven: Ik heb net nog het e.e.a geschreven. Kan iemand dit asap publiceren en/of mij een blog login kado doen? Op 13 december 2010 13:28 heeft Frank Fesevur f...@users.sourceforge.net het volgende geschreven: Martijn, Is is bijna niets gebeurd in het document, dus er valt ook niet veel te publiceren. Als ik de revisiegeschiedenis bekijk ben ik de enige die de afgelopen week iets in het document heeft geplaatst, maar de tweede helft van de week geen tijd gehad om dingen bij te houden. Werk en privé vragen soms ook tijd... Dus er staan drie items in en na de 7e niets meer. En ik heb trouwens nog geen inlog voor de blog en daar heb ik ook nog geen moeite voor gedaan zeg ik er direct bij (reden: zie alinea hierboven ;-) Gegroet, Frank Op 13 december 2010 12:37 heeft Martijn van Exel mart...@geodan.nl het volgende geschreven: Ha allemaal, Ik zie dat er nog geen weekbulletin is gepubliceerd? Wie gaat dat ff doen? Martijn -- Martijn van Exel Senior Researcher / Software Engineer - Geodan SR President Kennedylaan 1 1079 MB Amsterdam (NL) - Tel: +31 (0)20 - 5711 318 Fax: +31 (0)20 - 5711 333 - E-mail: mart...@geodan.nl Website: www.geodan.nl KvK-nummer: 33 247475 Disclaimer: www.geodan.nl/disclaimer - ___ 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 ___ 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] ODbL acceptance statistics for the Netherlands
Just for the ones who are interested in the ODbL acceptance: http://odbl.info.nu/ Discussion about this on the German forum (in English language if you want): http://forum.openstreetmap.org/viewtopic.php?id=10066 Enjoy your rank and the stats, Erik -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: wick...@jabber.org Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 signature.asc Description: OpenPGP digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] ODbL acceptance statistics for the Netherlands
It's funny to see how 3dShapes has over 80% of the nodes, and imagine this number is still counting (huge import in progress). Actually it's PD, but we aren't sure if the user account should accept the CT...or something along those lines... 2010/12/13 Erik Streb del Toro m...@erikstreb.de: Just for the ones who are interested in the ODbL acceptance: http://odbl.info.nu/ Discussion about this on the German forum (in English language if you want): http://forum.openstreetmap.org/viewtopic.php?id=10066 Enjoy your rank and the stats, Erik -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: wick...@jabber.org Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 ___ 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
Re: [OSM-talk-nl] ODbL acceptance statistics for the Netherlands
Als deze site op enige wijze iets te doen heeft met ODBL, nou dan mag odbl de spambox in. Welk arsch... zet er OSM data op een spam site Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Peter Verzonden: maandag 13 december 2010 17:44 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] ODbL acceptance statistics for the Netherlands It's funny to see how 3dShapes has over 80% of the nodes, and imagine this number is still counting (huge import in progress). Actually it's PD, but we aren't sure if the user account should accept the CT...or something along those lines... 2010/12/13 Erik Streb del Toro m...@erikstreb.de: Just for the ones who are interested in the ODbL acceptance: http://odbl.info.nu/ Discussion about this on the German forum (in English language if you want): http://forum.openstreetmap.org/viewtopic.php?id=10066 Enjoy your rank and the stats, Erik -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: wick...@jabber.org Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 ___ 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 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] ODbL acceptance statistics for the Netherlands
On 10-12-13 05:39 PM, Erik Streb del Toro wrote: Just for the ones who are interested in the ODbL acceptance: http://odbl.info.nu/ Discussion about this on the German forum (in English language if you want): http://forum.openstreetmap.org/viewtopic.php?id=10066 Enjoy your rank and the stats, Erik ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl Om de statistieken te ontdoen van de impact van de imports, ben ik wat met OO.o in de weer geweest. Ik heb me vanuit praktisch oogpunt beperkt tot degenen die minimaal 100 nodes op hun naam hebben staan. Dit zijn 684 accounts. Als importaccount heb ik de volgende accounts aangemerkt: 3dShapes, AND, AND_fixbot en nijmegen. Vooral de impact op de nodes is groot (93.6%). De aantallen: # nodes # ways# rels Totaal 400107335410322 56750 Totaal zonder import2561474 783295 20553 Deel zonder import6.40% 14.48%36.22% Er zijn dus relatief veel ways en vooral relaties door gewone gebruikers gewijzigd. Waarschijnlijk omdat het makkelijker is om bestaande ways en relaties te wijzigen, i.p.v. nodes; laat staan het tekenen van grote aantallen nieuwe nodes. Als ik puur alleen naar de wijzigingen kijk, met inbegrip van de import accounts, dan komen de volgende getallen uit de bus: # nodes # ways# rels Met import, voor ODbL 1351945 464027 12819 Met import, tegen ODbL386587884946295 43931 Met import, voor ODbL3.38% 8.58%22.59% Met import, tegen ODbL 96.62% 91.42%77.41% De aantallen voor ODbLzijn iets minder dan de aantallen die op de website staan. De eerste aantallen per elementtype (node, way, relation) is vermoedelijk op basis van de hele history. De aantallen in de tweede rij is het *verschil*, als alleen naar de laatste wijziging wordt gekeken. Het percentage is wel voor de volledige last edit berekend. Mijn aantallen zijn iets lager, vanwege de selectie van de grotere accounts. Ze zijn ook iets in het nadeel van de ODbL supporters. Dan nu de statistieken waarbij ik de vier genoemde importaccounts heb weggelaten: # nodes# ways# rels Zonder import, voor ODbL 1138245430621 12777 Zonder import, tegen ODbL1423229352674 7776 Zonder import, voor ODbL 44.44%54.98%62.17% Zonder import, tegen ODbL 55.56%45.02%37.83% Hier is duidelijk dat er een redelijke 50/50 verdeling is. De toename in ways en relaties ligt volgens mij ook aan wijzigingen van bestaande data. Oudere gebruikers hebben mogelijk hun account verlaten, en zullen dus ook eerder niet genegen zijn om met de ODbL / CT in te stemmen. Natuurlijk valt er op deze analyse ook het nodige aan te merken, maar het schept wel een duidelijker beeld van de situatie in Nederland. Een volgende analyse zou misschien alle users moeten meenemen, en ook een onderverdeling maken in gebruikers die vrijwillig instemden met de ODbL / CT, of gebruikers die pas recent een account aanmaken (user ID 281xxx). Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Betr: Re: ODbL acceptance statistics for the Netherlands
Bedankt Frank voor de interessante analyse.Volgens zijn bij "tegen" ODbL ook alle gebruikers meegeteld die zich (nog) niet uitgesproken hebben.#nodes #ways #rels Zonder import, voor ODbL 44.44% 54.98% 62.17% Zonder import, tegen ODbL 55.56% 45.02% 37.83% ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Betr: Re: ODbL acceptance statistics for the Netherlands
Quoting dbuss...@goudappel.nl: Bedankt Frank voor de interessante analyse. Volgens zijn bij tegen ODbL ook alle gebruikers meegeteld die zich (nog) niet uitgesproken hebben. #nodes #ways #rels Zonder import, voor ODbL 44.44%54.98%62.17% Zonder import, tegen ODbL 55.56%45.02%37.83% Inderdaad. Ik verwacht dat er maar een klein deel principieel tegen de ODbL en de CT zijn, maar een groter deel zich nog niet heeft kunnen of willen uitspreken. Een van de redenen die recent vaak werd genoemd is dat statistieken een vertekend beeld geven van de support door de imports. Ik hoop dat mijn bijdrage anderen helpt om een objectieve keuze te maken. Een andere reden dat mensen nog niet ingestemd hebben is dat men om geheel andere redenen zich niet langer met OSM bezighoudt. Het is lastig om hen te bereiken. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[Talk-br] Manutenção planejada
Amanhã haverá parada nos servidores do OpenStreetMap para manutenção planejada das 6:45 às 7:45 (Brasília). -- Forwarded message -- From: Grant Slater openstreet...@firefishy.com Date: Mon, Dec 13, 2010 at 12:24 PM Subject: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning To: Talk Openstreetmap t...@openstreetmap.org, annou...@openstreetmap.org OSM, Please copy this to local lists as appropriate. Tuesday 8:45am (14 December 2010 GMT/UTC+0) the API and editing on www.openstreetmap.org will be unavailable during hardware maintenance. The maintenance is expected to take 1 hour. Technical: Replacing a failed RAID Controller Battery. Regards Grant Part of the OSM Sysadmin Team ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Apresentação
Prezados, Me chamo Djavan Fagundes, sou de Belo Horizonte e comecei a contribuir com o OSM vendo apresentações do Samuel Vale e também do Arlindo Saraiva em eventos de Software livre. Estou um tanto atrasado em assinar a lista, mas antes tarde do que nunca! -- Djavan Fagundes E-mail | xmpp: dja...@comum.org http://djavan.comum.org/blog/ http://butequeiro.comum.org/ http://comum.org ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Apresentação
Opa Djavan, seja bem-vindo! 2010/12/13 Djavan Fagundes dja...@comum.org Prezados, Me chamo Djavan Fagundes, sou de Belo Horizonte e comecei a contribuir com o OSM vendo apresentações do Samuel Vale e também do Arlindo Saraiva em eventos de Software livre. Estou um tanto atrasado em assinar a lista, mas antes tarde do que nunca! -- Djavan Fagundes E-mail | xmpp: dja...@comum.org http://djavan.comum.org/blog/ http://butequeiro.comum.org/ http://comum.org ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Problem mit osm.pbf
Am 12.12.10 21:29, schrieb aighes: Hallo, die europe.osm.pbf müsste korrekt sein. Weil a) funktioniert sie unter Linux und b) funktionieren die daraus erstellten kleineren Extrakte. Wenn das pbf aber unter Windows aus den osm.bz2 erstellt wird (also nur --rx und --wb) gehen alle weiteren Bearbeitungsschritte. Weichen deine und Geofabrik-pbf größenmäßig voneinander ab? gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich anonymisiertre Tracks (nicht) hochladen?
Hi! Ich kenne den Hintergrund dieses Verhaltens nicht. Falls es allerdings beabsichtigt ist und nicht nur ein technisches Problem: Das Hochladen von Tracks ohne Zeitinformationen sollte definitiv möglich sein. Wenn das nicht geht ist die Konsequenz ganz einfach die, daß diejenigen, die sich aus Datenschutzgründen die Mühe machen, ihre Tracks vor dem Upload von diesen Infos zu strippen einfach gar keine Tracks mehr hochladen. Das kann wohl kaum im Interesse des Projekts sein. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Zeitlich-anonymisiertre-Tracks-nicht-hochladen-tp5829904p5829959.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Am 12.12.10 21:12, schrieb Stephan Knauss: On 12.12.2010 20:50, Andre Joost wrote: Hier werkelt übrigens Java 6 Update 22, und das schon ne geraume Weile. 32 bit oder 64 bit? 32bit unter XP. Ist aber wohl nicht die ursache. Ich hatte einen Fall bei dem die Relationen komplett gefehlt hatten. Und ich hatte als Quelle das asia.osm.bz2 Ja, das war das Plattenüberlaufproblem. ich hatte mir aber extra die europe.pbf gealden, die *nach* dem Neustart erzeugt und bereitgestellt wurde. Wenn du einen grep auf die Datei machst, sind da dann die Daten drin die Du erwartest? Lesbar sind die Daten ja wegen der Verschlüsselung nicht. Aber ich hatte die datei mit 7zip in handliche Stücke für meine FAT32-Wechselfestplatte zerlegt und auf nem anderen rechner zusammengebaut. Da wurden schon sämtliche 4 GB verarbeitet. Auf das osmosis-Ergebnis hatte das keine Einfluß. Da die europe.pbf bis zum 2.12.2010 wohl funktionert haben soll: Kann jemand mit laufender aktueller Datenbank rausfinden, welcher Knoten mit ID 45544258+x zwischen dem 01.12.2010 und 08.12.2010 bearbeitet wurde? Eventuell hat ein geänderter Knoten merkwürdige Tags, die mit Linux zu pbf verpackt sich nicht mit Windows entpacken lassen. Kannst du mit pbf2osm die Datei umwandeln? Sind dann die entsprechenden Daten vorhanden? Ist ein Fehler im pbf auszuschließen? http://git.openstreetmap.nl/index.cgi/pbf2osm.git/ Wenn ich denn wüsste, wie man das Zeugs auf seinen Rechner bekommt ;-( Gibts da eventuell ne fertige exe für Windows? Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich anonymisiertre Tracks (nicht) hochladen?
NopMap schrieb am 13.12.2010 09:04: Ich kenne den Hintergrund dieses Verhaltens nicht. Falls es allerdings beabsichtigt ist und nicht nur ein technisches Problem: Das Hochladen von Tracks ohne Zeitinformationen sollte definitiv möglich sein. +1 Wenn das nicht geht ist die Konsequenz ganz einfach die, daß diejenigen, die sich aus Datenschutzgründen die Mühe machen, ihre Tracks vor dem Upload von diesen Infos zu strippen einfach gar keine Tracks mehr hochladen. Das kann wohl kaum im Interesse des Projekts sein. Oder der Fall, dass die Zeitstempel in der GPX Datei durch eine Konvertierung verloren gegangen sind. Ist mir passiert, da war ich froh, dass ich per GPX Editor fake 1970-Timestamps einbauen konnte, so dass ich den Track dann überhaupt hochladen konnte. -- Mit freundlichen Grüßen Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation 938868
Am 13.12.10 08:03, schrieb Matthias Versen: Hi ! Die Relation 938868 is mir in Garys Relation check aufgefallen. Der Server weigert sich die Relation rauszurücken was wahrscheinlich an den 2700+ Membern liegt. Also http://www.openstreetmap.org/api/0.6/relation/938868 tuts. Die ersten Elemente sind die Grenze zwischen Deutschland und Dänemark. Nach dem Sinn musst du die Ersteller fragen... Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation 938868
Am 13.12.2010 08:03, schrieb Matthias Versen: Die Relation 938868 is mir in Garys Relation check aufgefallen. Kann mir einer sagen um was es sich dabei handelt ? Der name Tag fehlt und land_area=administrative sagt mir nicht viel. Das ist offenbar ein Multipolygon, welches sämtliche administrativenGrenzen und Küstenlinien Dänemarks enthält. Wenn du mehr wissen willst,, solltest du den User polderrunner, der dieses Monster zuletzt angefasst hat, direkt anschreiben. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie bestimmt Skobbler/Mapdust fehlende maxspeed-Tags?
Hallo, ich habe im Wiki bereits gefunden, wie der OpenRouteService nicht vorhandene maxspeed-Tags ersetzt. Weiß aber auch jemand wie Skobbler das macht? Oder macht das schon Mapdust für Skobbler? Werden da auch einfach Werte anhand des Straßentypen gesetzt? Danke! Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nationalpark eintragen
Am 13.12.2010 01:26, schrieb Stephan Wolff: Bei vielen Gemeindegrenzen und Naturschutzgebietsgrenzen kann man den Verlauf anhand von Landsat- oder Bingluftbildern gut erraten. Es ist sehr unwahrscheinlich, dass Grenzen quer durch Wohngebiete und über Äcker verlaufen. sehr unwahrscheinlich nicht! das machen nicht mal Staatsgrenzen (zumindest ein Haus kenne ich wo die Grenze mitten durch läuft, auch andere kapriolen dieser Grenze sind mir bekannt habe 20 Jahre an der D/NL Grenze gewohnt). die Gemeindegrenzen hier (Simmerath/Monschau) wären auch schwierig zu erkennen. Viel wahrscheinlicher ist es, dass die Grenze genau hinter dem Wohngebiet, zwischen den Äckern oder entlang eines Baches verläuft. nein! Bäche etc habe die Eigenschaft ihren Lauf zu verändern ... Äcker wurden zusammengelegt ... Einen Nationalpark kann man auf diese Weise allerdings nicht erraten und Steffens Vorgehen ist natürlich nicht zulässig. habs auch zurückgenommen! aber auch hier gabs stellen die ganz klar waren: Rursee, Straßen... Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Kommunen: place vs multipolygon
Am Sonntag 12 Dezember 2010, 17:24:48 schrieb Georg Feddern: Einspruch in allen Punkten - zumindest bei Mapnik, Osmarender habe ich jetzt nicht genauer geprüft! ;-) http://www.openstreetmap.org/?lat=54.3271lon=10.385zoom=14layers=M http://www.openstreetmap.org/?lat=54.3271lon=10.385zoom=13layers=M Interessant. Dann ist das hier in der Umgebung wohl immer zufällig so dass die geometrische Mitte in den Ort fällt und das Rendering durch andere Icons und Texte dann unterdrückt wird. Ich habe nämlich die PLZ und Gemeindegrenze hier erst vor ner Weile mal gepflegt und habe noch nie ein solches Rendering gesehen. Das ist dann natürlich Dummheit von Mapnik, meiner Meinung nach. Gruß, Bernd -- Ist es nicht merkwürdig, daß jeden Tag genau soviel passiert, wie in die Zeitung paßt? 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] Ältere Datensätze
Am 02.12.2010 21:27, schrieb Frederik Ramm: Hi, Tom Müller wrote: Kann man die Polygon-Dateien für osmosis irgendwo herunterladen? http://www.remote.org/frederik/tmp/berlin.poly http://www.remote.org/frederik/tmp/niederbayern.poly Bye Frederik Hallo Frederik, kannst Du mir u.U. auch noch das Polygon für Hamburg zur Verfügung stellen? Danke! Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Kommunen: place vs multipolygon
Hallo. Am Sonntag 12 Dezember 2010, 19:14:03 schrieb Tirkon: Von daher fände ich eine Verknüpfung sinnvoll, die dem Renderer das anzeigt. Dann braucht man auch die Infotags wie z.B. die Einwohnerzahlen nur einmal anzugeben, weil sie über die Verknüpfung gefunden werden können. Ansonsten müsste man sie zweimal pflegen. Man sollte sich dann nur einigen, wohin man sie schreibt. Es ist doch ein wesentlicher Unterschied ob man von der Einwohnerzahl einer Gemeinde (aus z.B. 5 Dörfern) und der Einwohnerzahl eines Dorfes redet. Explizites Verknüpfen ist meiner Ansicht nach nicht besonders sinnvoll, da das durch die gegrafische Lage schon deutlich wird. Die nach-außen-Verknüpfung über is_in-Tags an den Nodes macht viel Sinn, Relationen allerdings nicht, da das dann nur redundante Sammelrelationen werden. Gruß, Bernd -- To criticize the incompetent is easy; it's more difficult to criticize the competent. 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] Benennung von Kernorten einer Gemeinde (boundary=administrative)
Am 13.12.2010 03:18, schrieb Matthias Versen: bundesrainer wrote: Im Falle von Landkreisen fände ich den Namen Landkreis XY trotz des Präfixes sinnvoll, denn so lautet die verbreitete Bezeichnung. Kann dann aber vom Renderer etc. bei vorhandenem name:prefix entschieden werden. Zusammensetzen ist leicht, Zerlegen schwer. Im allgemeinen wird bei den Kreisen der prefix Landkreis , Kreis mitbenutzt aber das ist nicht überall der Fall. Die Bezeichnung wird meistens nur dort benutzt wo eine verwechselungsgefahr besteht. Es gibt z.b. die Stadt Höxter und den Kreis Höxter. Bei Kreisfreien Städten hat die Relation den admin_level eines Kreises aber der prefix Kreis wird nicht benutzt. Dann gibt es noch Kreise die einen eindeutigen Namen haben, dort wird umgangssprachlich auch selten der name:prefix benutzt weil es auch so eindeutig ist. BeispielKreis Lippe ...und dann gibt es die ganz eindeutigen Fälle, in denen kein Präfix steht, weil das bereits Teil des Namens ist, wie z.B. Rhein-Sieg-Kreis. Die Software kann mit dem name:prefix entscheiden ob der prefix benutzt wird oder nicht. So kann man z.b. bei 2 gleichen Namen den Prefix einblenden. +1 Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Applet
auch bei mir: unter Win XP mit Firefox funktioniert das Applet nicht. Bei mir bleibt der Bildschirm hingegen weiss, nicht schwarz. Aber unter Win XP mit dem IE8 funktioniert das Applet reibungslos. Nur muss ich die Anmeldedaten zweimal eingeben. Unter Ubuntu funktioniert das Applet mit Firefox. Aber auch dort muss ich die Anmeldedaten doppelt eingeben. Gruss Fred Am 12.12.2010 22:27, schrieb Chris66: Hallo, ich weiss nicht ob Sie es schon wussten aber JOSM gibt's nun auch als Applet: http://josm.openstreetmap.de/applet Kurztest meinerseits (XP): FireFox: schwarzer Bildschirm nach der Anmeldung. Chrome: Hier musste ich mich 3 mal in 2 verschiedenen Anmeldeboxen anmelden, aber dann läuft es. Applet ist etwas zu groß, so dass es rechts eine Scrollbar gibt, und die mittlere Maustaste führt gleichzeitig zum Zoomen und Vertikalrollen des Fensterinhalts. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich anonymisiertre Tracks (nicht) hochladen?
Ist mir passiert, da war ich froh, dass ich per GPX Editor fake 1970-Timestamps einbauen konnte, so dass ich den Track dann überhaupt hochladen konnte. Du brauchst ein Script welches einfach von Punkt zu Punkt eine Sekunde hochzählt. Das gibt zwar Probleme für diejenigen, die die Geschwindigkeit farblich darstellen. Aber immernoch besser als gar kein hochgeladener Track. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ältere Datensätze
Hallo, On 12/13/10 10:20, Tom Müller wrote: kannst Du mir u.U. auch noch das Polygon für Hamburg zur Verfügung stellen? Liegt jetzt am selben Ort. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ältere Datensätze
Am 13.12.2010 13:30, schrieb Frederik Ramm: Hallo, On 12/13/10 10:20, Tom Müller wrote: kannst Du mir u.U. auch noch das Polygon für Hamburg zur Verfügung stellen? Liegt jetzt am selben Ort. Bye Frederik Vielen Dank mal wieder! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wartung am Dienstag vormittag
Hallo, Dienstag 14.12. von ca. 9:45 bis 10:45 wird der OSM-Datenbankserver heruntergefahren. In der Zeit ist das Herunter-/Hochladen von Daten nicht moeglich. 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
[Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Hi ! es gibt BING und andere Image-Datenquellen und bei den Objekten sollten nach Möglichkeit source= zugewiesen werden. Immer das ganze manuell von Hand ist etwas aufwending auf Dauer und daher bin ich am überlegen wie dieses in JOSM machbar wäre. Bevor ich ein Ticket erstelle wollte ich wissen wie Ihr darüber denkt und was es vielleicht schon für Ideen gibt ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
On Mon, 13 Dec 2010 16:03:29 +0100 Jan Tappenbeck o...@tappenbeck.net wrote: es gibt BING und andere Image-Datenquellen und bei den Objekten sollten nach Möglichkeit source= zugewiesen werden. Immer das ganze manuell von Hand ist etwas aufwending auf Dauer und daher bin ich am überlegen wie dieses in JOSM machbar wäre. +1 ... Aber: bitte mit Häkchen vor der jeweiligen Quelle, so dass man es ggfs. ausstellen kann. Bevor ich ein Ticket erstelle wollte ich wissen wie Ihr darüber denkt und was es vielleicht schon für Ideen gibt ? Mach's auf, wenn Du's für sinnvoll hälst :) Hanno ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
On Mon, 13 Dec 2010 16:11:48 +0100 Hanno Hecker vetinari+...@ankh-morp.org wrote: On Mon, 13 Dec 2010 16:03:29 +0100 Jan Tappenbeck o...@tappenbeck.net wrote: es gibt BING und andere Image-Datenquellen und bei den Objekten sollten s/Objekten/Changeset/ ... nach Möglichkeit source= zugewiesen werden. Immer das ganze manuell von Hand ist etwas aufwending auf Dauer und daher bin ich am überlegen wie dieses in JOSM machbar wäre. +1 ... Aber: bitte mit Häkchen vor der jeweiligen Quelle, so dass man es ggfs. ausstellen kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Hallo, über die Suche kannst du dir alle geänderten Objekte markieren lassen. Evtl. musst du dann im Anschluss die Auswahl noch weiter eingrenzen... Du könntest dir natürlich auch ein Preset schreiben, was per Knopfdruck ein source=bing an das Objekt pappt. Das ganze automatisch zu machen halte ich für falsch. Weil nicht alles, was man einzeichnet, während bing im Hintergrund ist, ist auch von bing abgemalt. Bspw. die Radweg-Relation oder den Weg, den ich per GPS aufgezeichnet habe. Das lässt sich nicht automatisch regeln. Allgemein halte ich aber rcht wenig von source-Tag. Mitunter kann ein Objekt mehrere sourcen haben. soll man jetzt auch deshalb den Weg aussplitten? Oder gibt es dann auch unter-taggs wie amenity:source=*. Bei mir kommt das Bing in den Changeset-Kommentar. Diesen kann man sich für jede Version des Objekts über osm.org ansehen. Viele Grüße Henning -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-Source-Vereinfachung-der-Erfassung-tp5831026p5831063.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: Idee für Image-Tool
Hi ! in JOSM gibt es ein Plugin um Gebäude zeichnen zu können. Nun stehe ja immer mehr Bilder zur Verfügung und bei der Erfassung Landuse gibt es im Bereich der neuen Bundesländer oftmals riesige Felder mit großen grünen Inseln. Es wäre schön wenn über einen Algorithmus die Abgrenzung des Kontrastes geben könnte der diesen automatisch zeichnet oder zumindest dabei unterstützt. Meint einer das wäre machbar ??? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bing und 4326
Hallo zusammen, gibt es ne Möglichkeit die Bing-Luftbilder im Josm auch in EPSG: 4326 zu bekommen? Bzw. ist da was angedacht oder wird das von Microsoft ausgeschlossen? -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 13.12.2010 16:17, schrieb aighes: Hallo, über die Suche kannst du dir alle geänderten Objekte markieren lassen. Evtl. musst du dann im Anschluss die Auswahl noch weiter eingrenzen... wieder manuelle Arbeit Du könntest dir natürlich auch ein Preset schreiben, was per Knopfdruck ein source=bing an das Objekt pappt. mache ich auch schon und sehr nervig auf Dauer. Das ganze automatisch zu machen halte ich für falsch. Weil nicht alles, was man einzeichnet, während bing im Hintergrund ist, ist auch von bing abgemalt. Bspw. die Radweg-Relation oder den Weg, den ich per GPS aufgezeichnet habe. Das lässt sich nicht automatisch regeln. man könnte es an die Aktivität des Bildes zu koppeln Allgemein halte ich aber rcht wenig von source-Tag. Mitunter kann ein Objekt mehrere sourcen haben. soll man jetzt auch deshalb den Weg aussplitten? Oder gibt es dann auch unter-taggs wie amenity:source=*. Bei mir kommt das Bing in den Changeset-Kommentar. Diesen kann man sich für jede Version des Objekts über osm.org ansehen. Viele Grüße Henning Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am Montag 13 Dezember 2010, 16:03:29 schrieb Jan Tappenbeck: es gibt BING und andere Image-Datenquellen und bei den Objekten sollten nach Möglichkeit source= zugewiesen werden. Finde ich nicht und mache ich auch nicht. Das war mal eine (gute) Idee, aber in der Praxis zeigt es sich doch, dass es sehr umständlich und wenig nützlich ist. Es gibt Fälle da will der Luftbildspender eine Nennung und da mag source passend sein. Vor ner Weile war es noch gut, wenn man eine definitiv schlechte Quelle hatte, dass man source=Landsat dran hängt, dass der nächste nicht an seinem GPS- Signal zweifelt sondern munter seine Daten als besser sehen darf. Insbesondere seit den BING-Bildern ist es aber meiner Meinung nach nur noch umständlich und Verschwendung, dieses Tag zu setzen. Ich fände es sinnvoll, wenn der Editor beim Changeset automatisch Tags aufgrund der aktivierten Ebenen setzen würde, also welchen WMS ich benutzt habe oder ob ich GPS-Tracks geladen/geöffnet habe. Gruß, Bernd -- Arme haben Arme. Arme haben Beine. Beine haben keine Arme. Arme Beine! 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] JOSM: Idee für Image-Tool
Hallo, Am Montag 13 Dezember 2010 schrieb Jan Tappenbeck: Es wäre schön wenn über einen Algorithmus die Abgrenzung des Kontrastes geben könnte der diesen automatisch zeichnet oder zumindest dabei unterstützt. Du könntest versuchen, das Plugin http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Lakewalker dahin gehend anzupassen. Gruß, Carsten -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing und 4326
geo.osm geo@googlemail.com wrote: gibt es ne Möglichkeit die Bing-Luftbilder im Josm auch in EPSG: 4326 zu bekommen? Dazu müsste man sie umprojizieren, weil das nun mal die üblichen Tiles in Google Merkator sind. Was ist denn der Grund dafür, dass Du verzerrte Bilder haben möchtest? Ich bin ja ohnehin der Meinung, dass man den lat/long Mode im josm ausbauen sollte. Aufgrund von diesem wurden IMO schon viel zu viele rautenförmige Häuser und Sportzplätze verbrochen. Sven -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Hallo, aighes wrote: Allgemein halte ich aber rcht wenig von source-Tag. Mitunter kann ein Objekt mehrere sourcen haben. soll man jetzt auch deshalb den Weg aussplitten? Oder gibt es dann auch unter-taggs wie amenity:source=*. Bei mir kommt das Bing in den Changeset-Kommentar. Diesen kann man sich für jede Version des Objekts über osm.org ansehen. Ja, ich wuerde auch ein source: am Objekt nur in Ausnahmefaellen setzen; das mit dem Changeset finde ich besser. 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] Zeitlich anonymisiertre Tracks (nicht) hochladen?
Johann H. Addicks schrieb am 13.12.2010 13:20: Ist mir passiert, da war ich froh, dass ich per GPX Editor fake 1970-Timestamps einbauen konnte, so dass ich den Track dann überhaupt hochladen konnte. Du brauchst ein Script welches einfach von Punkt zu Punkt eine Sekunde hochzählt. Das gibt zwar Probleme für diejenigen, die die Geschwindigkeit farblich darstellen. Aber immernoch besser als gar kein hochgeladener Track. Dann ist mir ein Track lieber der erkennbar Blödsinn im timecode hat :-) -- Mit freundlichen Grüßen Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing und 4326
Hallo Sven, Dazu müsste man sie umprojizieren, weil das nun mal die üblichen Tiles in Google Merkator sind. das ist mir schon klar. Was ist denn der Grund dafür, dass Du verzerrte Bilder haben möchtest? Ich habe andere WMS-Services eingebunden, die nur WGS84 oder UTM zurückgeben. Und die würde ich gerne mit den Bing-Luftbildern überlagern. Ich bin ja ohnehin der Meinung, dass man den lat/long Mode im josm ausbauen sollte. Aufgrund von diesem wurden IMO schon viel zu viele rautenförmige Häuser und Sportzplätze verbrochen. da hast du sicherlich recht. Wenn ich etwas von Luftbilder abzeichne verwende ich auch kein WGS84. -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
André Joost schrieb am 13.12.2010 09:13: Da die europe.pbf bis zum 2.12.2010 wohl funktionert haben soll: Die Datei ist jetzt 4,1GB gross. Hat sie zufaellig in letzter Zeit die 4GB Grenze ueberschritten? Das wuerde allerdings auch nicht erklaeren, wieso eine selbstgepackte pbf-Datei auf einem Windof-System funktioniert, es sei denn, dass schon beim packen auf dem Windof-Rechner ein Teil verloren geht und die pbf-Datei deshalb gar nicht vollstaendig waere. Gibt es irgendwo eine andere pbf-Datei groesser als 4GB, die man mal zum Vergleich probieren koennte? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Am 11.12.2010 19:46, schrieb aighes: Ich hatte mir europe.osm.bz2 vom Donnerstag gezogen und mit osmosis 0.38 unter Win selber nach pbf gewandelt. Damit funktionierte dann sowohl osmosis als auch später der splitter. Hi hast du vom selben Zeitpunkt noch das Geofabrik .osm.pbf so dass wir vergleichen könnten? Nach meinem Verständnis brauchen wir - europe.osm.pbf von der Geofabrik - europe.osm.pbf unter Windows erstellt aus europe.osm.bz2 von der Geofabrik erstere scheint unter Win nicht zu funktionieren, letztere schon. Beide sollten eigentlich identisch sein. Der Unterschied dazwischen beinhaltet die Ursache des Problems. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Hallo, nur an den 4GB kann es nicht liegen. Wenn du mal eine pbf unkomprimiert abspeicherst, dann ist die locker größer, war auch früher schon so. Ich könnte so eine pbf aus dem bz2 unter Win erstellen. Nur fürs hochladen reicht mein Webspace nicht aus. Wenn jemand dafür Abhilfe weiß nur zu. -- View this message in context: http://gis.638310.n2.nabble.com/Problem-mit-osm-pbf-tp5808951p5831642.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Da war ich etwas voreilig... Ich organisiere mir gerade beide Dateien von heute. Wie könnte man sie denn vergleichen? Dann könnte ich das morgen mal machen. Viele Grüße, Henning -- View this message in context: http://gis.638310.n2.nabble.com/Problem-mit-osm-pbf-tp5808951p5831685.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Hi! Unter *nix könnte ich mir md5sum zum Vergleichen vorstellen. Bei gleicher interner binärer Struktur muss die selbe md5summe raus kommen. Gruß Carsten Am 13.12.2010 19:09, schrieb aighes: Da war ich etwas voreilig... Ich organisiere mir gerade beide Dateien von heute. Wie könnte man sie denn vergleichen? Dann könnte ich das morgen mal machen. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Hi, aighes wrote: Da war ich etwas voreilig... Ich organisiere mir gerade beide Dateien von heute. Wie könnte man sie denn vergleichen? Dann könnte ich das morgen mal machen. Also, es waere super, wenn Du die .osm.bz2 mit Osmosis in eine .pbf umwandeln koenntest. Wenn ich Dich richtig verstehe, geht diese neue .pbf dann ja ueberall, wahrend die alte nicht geht? Vergleichen: natuerlich erstmal die Dateilaenge. Bei gleicher Laenge gibt es ein md5sum.exe, mit dem man die Pruefsumme der Datei bestimmen kann - aber wenn beide Dateien unterschiedlich lang sind, kann man sich das schon sparen. Dann waere es hilfreich, wenn Du die so erzeugte, funktionierende PBF irgendwohin hochladen koenntest, so dass man sie mit der nicht funktionierenden vergleichen kann. Zur Sicherheit gibt auch Dateilaenge der nicht funktionierenden, von Geofabrik heruntergeladenen .osm.pbf an, damit wir es mit der richtigen Datei vergleichen... 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] Problem mit osm.pbf
Hallo Frederik, mit welchen Parametern im --wb erzeugst du denn das europe.osm.pbf? Diese sollte ich ja dann genauso wählen. Könntest du die Hashes von den heutigen Daten mir zukommen lassen (pbf und bz2), um dort Fehler auszuschließen. An der Bandbreite bei mir schietert es nicht. Ich hab allerdings keine Möglichkeit, diese Datenmenge irgendwo online zu speichern. Viele Grüße, Henning -- View this message in context: http://gis.638310.n2.nabble.com/Problem-mit-osm-pbf-tp5808951p5831755.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 13.12.2010 16:34, schrieb Bernd Wurst: Ich fände es sinnvoll, wenn der Editor beim Changeset automatisch Tags aufgrund der aktivierten Ebenen setzen würde, also welchen WMS ich benutzt habe oder ob ich GPS-Tracks geladen/geöffnet habe. Ich hänge den Source-Tag eigentlich nur noch an das jeweilige Changeset. Ich stimme Dir vollumfänglich zu, dass das genannte Vorgehen eigentlich nur dann sinnvoll ist, wenn man von sehr schlechtem Bildmaterial wie Landsat abzeichnet. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Kommunen: place vs multipolygon
Andreas Labres l...@lab.at wrote: On 12.12.10 15:45, Tirkon wrote: Falls beide existieren sollen: Ein Kartenrenderer rendert dann den Ortsnamen zweimal. Er zeichnet dabei den Ortsnamen aus dem multipolygon offensichtlich in einen geometrisch ermittelten Mittelpunkt. Sollte place in die multipolygon-Relation aufgenommen werden oder durch eine andere Relation damit verknüpft werden? Das admin-boundary Multipolygon definiert das Gebiet der jeweiligen administrativen Entität. Und der place node definiert die Beschriftung. Nicht nur beim Rendern führt das zu doppelten Einträgen, vor allem auch Nominatim denkt sich rund um die place nodes abstruse Dinge aus (Beispiele gern auf Wunsch privat...). Es wäre schon sinnvoll, mal diese Dinge in Beziehung zu setzen, zB indem man beim admin-boundary MP den place node als role label hinzufügt. Dann hätten Renderer die Chance, Beschriftungen passend zu platzieren, und Nominatim müßte dieses in Beziehung stehen auch verstehen, indem er dann eben weiß: Ok, diesen place node habe ich schon in admin_level=#, ich muß ihn also nicht nochmal irgendwie mehr oder weniger wahllos in die Hierarchie einbauen. Bzw. in AT ist es ja so, dass die Admin-Grenzen bis zur Gemeindeebene hin (in [zumindest] Wien und Graz sogar bis zum Stadtbezirk) definiert sind, da könnte er sich dieses place-node-Raten grundsätzlich sparen... Ich sehe, wir verstehen uns. :-) Damit wäre auch das ganze Ordnungsgeraffel wie z.B. is_in nicht mehr notwendig. Die admin-level und deren Verknüpfung über die boundary-multipolygon-Grenzen geben alles Notwendige wesentlich detaillierter her. In der hiesigen Region wären nach meinen bisherigen Ermittlungen alle Grenzverläufe zumindest bis zur Ortsteilgrenze definiert. Und genau so detailliert hätte ich es gern zunächst hier in der Modellregion und später Niedersachsen-weit in OSM. Auch die Straßenverzeichnisse sollen möglichst diesen Detaillierungsgrad aufweisen. Daran arbeite ich zur Zeit. Und daher war diese Klärung notwendig. Die Idee mit der role label ist genial. Hast Du auch einen Vorschlag, was wir mir den bisher am place hängenden Beschreibungstags machen? Lassen wir die dranhängen? Beispiel: http://www.openstreetmap.org/browse/node/240102131 Diese Lösung könnte auch das Rendern von Landkreis-, Städte-, Gemeinde-, und Ortsteilnamen in den verschiedenen Zoomstufen verbessern. Beim Hineinzoomen könnte zunächst der Name einer Gemeinde gerendert werden und erst später ihre Ortsteile. Wenn der Renderer sehr intelligent ist, könnte er sogar bei einer hohen Zoomstufe die Verortung des Labels ignorieren und den Schriftzug eines Namens in Hohlschrift über den gesamten Bereich der benannten Gebietskörperschaft unter dezenter Hervorhebung der Grenze ausdehnen. Gru0 Trikon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Applet
Am 13.12.2010 13:12, schrieb Fred Jelk: auch bei mir: unter Win XP mit Firefox funktioniert das Applet nicht. Bei mir bleibt der Bildschirm hingegen weiss, nicht schwarz. Aber unter Win XP mit dem IE8 funktioniert das Applet reibungslos. Nur muss ich die Anmeldedaten zweimal eingeben. Wenn ich in meinem FF die Plugins Adblock+ und Greasemonkey deaktiviere geht es. Hat schon jemand rausgefunden, wie man seine Einstellungen abspeichern kann? Bei upload Prefs kommt eine Fehlermeldung. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Hallo, aighes wrote: mit welchen Parametern im --wb erzeugst du denn das europe.osm.pbf? Diese sollte ich ja dann genauso wählen. Mit compress=deflate, aber das ist eh der Default; sonst nix spezielles. Die aktuellen md5summen und Groessen sind: europe.osm.bz2 cd8439ecfdb7e1012704c4cd6914abb8 size 6567425820 europe.osm.pbf 9d278ee963925ed34701431b8573e0bf size 4448335290 europe.osm f933a3dda305d75aff2df3dacedac4e0 size 85688818446 An der Bandbreite bei mir schietert es nicht. Ich hab allerdings keine Möglichkeit, diese Datenmenge irgendwo online zu speichern. Kannst Du, wenn es soweit ist, eventuell bei Dir auf dem Rechner, auf dem Du die Daten erzeugst, einen kleinen Webserver starten, so dass ich die Datei von Dir mit wget abholen und bei mir speichern kann? Ansonsten wuerde ich Dir einen FTP-Account o.ae. einrichten, an den Du die Datei hochladen koenntest. 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] JOSM: Source = * - Vereinfachung der Erfassung
Moin Jan, On Mon, 13 Dec 2010, Jan Tappenbeck wrote: Bevor ich ein Ticket erstelle wollte ich wissen wie Ihr darüber denkt und was es vielleicht schon für Ideen gibt ? hm, von vor einem Jahr: https://josm.openstreetmap.de/ticket/4181 wenigstens die letzten 10 Möglichkeiten behalten - ein paar vordefinierte wären schon prima ... Gruß, Schusch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Moin, Hier hätte sich angeboten, in einer die BRD (bzw das entsprechende Gebiet) umschließenden bounding box nur die Bahngleise herunterzuladen. (bzw railway=*) Wie geht das? Ich kann zwar rudimentär mit josm umgehen und habe gefunden wo ich teile der Welt runterladen kann... Aber an sich macht dies doch nur den Unterschied wo die rechenlast ensteht, oder? bei deiner Variante halt auf dem Srever - bei der von uns auf unsren Rechnern. Und das Routing wäre trotzdem notwenig, da der Castor nicht alle möglichen Schienen benutzen kann, weil er zu schwer ist für einzelne Strecken. Es gibt nur wenige zugelassene Strecken... Liebste Grüße sandro ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Moin, Das hier könnte das sein nach dem du suchst: http://tiledrawer.com/ das ist ja schick, immer wieder verwundert was sich so alles um OSM so sammelt ;) Wenn ich das richtig verstehe wird hier eine Karte auf einer Amazon E3 gerendert, wobei ich ein Style angeben kann und sonst noch angebe, wo er die Daten herhohlen soll und dann rendert der das durch, wobei ich selber aber einen Amazon E3 Account brauche... Liebste Grüße sandro ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Hallo, On 12.12.2010 22:41, Jonas K. wrote: Wie wäre es mit den Tiles von MapQuest? http://developer.mapquest.com/web/products/open/map Es gäbe auch Microsoft, die allerdings nur mit Silverlight über ihr CDN liefern. Auch da ist sicher genügend Leistung da um mit ein paar Tausend Zugriffen pro Sekunde fertig zu werden. Bäh Microdoof nene das ist ja den Teufel mit dem Belzebub austreiben. Aber nochmals vielen Dank für die vielen Antworten und Möglichkeiten der Einbindung von OSM auf castorticker. Ich werde mal die Wochen mir das alles mal anschauen und dann weiter fragen ;) Aber eigentlich ist mein Nerdherz nur zufrieden, wenn ich selber einen Server aufgesetzt habe und eine Infrastrucktur schaffe die das selbständig verarbeitet, aber das muss natürlich abgewogen werden mit dem Aufwand und der Berücksichtung von benutzten Resourcen... Liebste Grüße sandro ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Hallo, Sandro wrote: Aber eigentlich ist mein Nerdherz nur zufrieden, wenn ich selber einen Server aufgesetzt habe und eine Infrastrucktur schaffe die das selbständig verarbeitet, Deine Anwendung ist insofern ungewoehnlich als dass Dein Server vermutlich nur einen Bruchteil aller denkbaren Karten-Tiles braucht und ferner, wie ich annehme, auch nicht darauf angewiesen ist, stets die aktuellsten Tiles zu haben. Du koenntest also, anstatt eine komplizierte Live-Rendering-Engine aufzusetzen, einfach alles vorberechnen, was gebraucht wird, das auf einen normalen Webserver werfen und fertig. 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] Castorticker
On 13.12.2010 22:47, Sandro wrote: Das hier könnte das sein nach dem du suchst: http://tiledrawer.com/ das ist ja schick, immer wieder verwundert was sich so alles um OSM so sammelt ;) Wenn ich das richtig verstehe wird hier eine Karte auf einer Amazon E3 Ich glaube es ist EC2, aber du scheinst es verstanden zu haben. Das schöne an der Lösung ist, dass du dir keine Sorgen um die Leistung machen musst. Es ist einfach genug da und du zahlst nach Verbrauch. Ansonsten musst du halt einen Server haben der sich 11 Monate im Jahr langweilt um im November ausgelastet zu sein. So ganz habe ich nicht verstanden wie viele Zugriffe du erwartest. Aber wenn du nur mit einer Textdatei 1GB/h bekommst sind das bei 10kb Text etwa 30 Hits pro Sekunde. Wenn deine Karte 5x5 Tiles anfordert musst du 750 Tiles pro Sekunde liefern können. Im dicht besiedelten Deutschland sind die Tiles recht groß, 25k dürften die haben. Damit lieferst du knapp 20 MB/s aus. Mal 60 Stunden hohe Last angesetzt komme ich auf 4TB und vielleicht nochmal 6TB für den Rest des Monats. Das sind Größenordnungen bei denen ein typische Webhosting Package wohl nicht ausreicht. Vorberechnete Tiles machen es aber leichter einen Server zu haben der das stemmen kann. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Am 14. Dezember 2010 00:01 schrieb Stephan Knauss o...@stephans-server.de: On 13.12.2010 22:47, Sandro wrote: Das hier könnte das sein nach dem du suchst: http://tiledrawer.com/ das ist ja schick, immer wieder verwundert was sich so alles um OSM so sammelt ;) Wenn ich das richtig verstehe wird hier eine Karte auf einer Amazon E3 Ich glaube es ist EC2, aber du scheinst es verstanden zu haben. Das schöne an der Lösung ist, dass du dir keine Sorgen um die Leistung machen musst. Es ist einfach genug da und du zahlst nach Verbrauch. Außer natürlich in dem Fall, dass man Amazon nicht passt und sie einen rauswerfen - wie gerade geschehen. Ansonsten musst du halt einen Server haben der sich 11 Monate im Jahr langweilt um im November ausgelastet zu sein. So ganz habe ich nicht verstanden wie viele Zugriffe du erwartest. Aber wenn du nur mit einer Textdatei 1GB/h bekommst sind das bei 10kb Text etwa 30 Hits pro Sekunde. 10 KB Text, aber 320 KB an Bildern, CSS, Javascript, etc. Die werden bei den meisten Besuchern nur einmalig geladen, machen aber sicher einen messbaren Anteil am Traffic aus. Wenn deine Karte 5x5 Tiles anfordert musst du 750 Tiles pro Sekunde liefern können. Im dicht besiedelten Deutschland sind die Tiles recht groß, 25k dürften die haben. Damit lieferst du knapp 20 MB/s aus. Mal 60 Stunden hohe Last angesetzt komme ich auf 4TB und vielleicht nochmal 6TB für den Rest des Monats. Das sind Größenordnungen bei denen ein typische Webhosting Package wohl nicht ausreicht. Vorberechnete Tiles machen es aber leichter einen Server zu haben der das stemmen kann. Hier gehst Du davon aus, dass die Tiles nicht gecached werden. Ich glaube, das ist in der Regel falsch. Bei so einem Ticker werden viele Leute die Seite mehrfach neu laden. In dem Fall werden die Tiles nicht neu angefordert werden müssen. Wie Frederik schon vorgeschlagen hat: Einmal Rendern und in ein Verzeichnis mit sauber eingestellten Cache-Anweisungen legen. (Default auf dem Server scheint bei maxage=10 Jahre zu liegen. Das sollte reichen) Und wenn man die Karte nicht bildschirmfüllend braucht, sondern sie zB in die Sidebar packt (unter Strecke), dann sollten auch 4 Tiles reichen. Grüße, jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Hallo, Außer natürlich in dem Fall, dass man Amazon nicht passt und sie einen rauswerfen - wie gerade geschehen. Ja Amazon ist sicher auch nicht mein Traumhoster aber tiledrawer.com hört sich halt wirklich sehr einfach an ;) 10 KB Text, aber 320 KB an Bildern, CSS, Javascript, etc. Die werden bei den meisten Besuchern nur einmalig geladen, machen aber sicher einen messbaren Anteil am Traffic aus. Naja in den letzten Tagen habe wir alle Bilder auf einen externen server gepackt, so das wir diese Last gar nicht mehr hatten... Hier gehst Du davon aus, dass die Tiles nicht gecached werden. Ich glaube, das ist in der Regel falsch. Bei so einem Ticker werden viele Leute die Seite mehrfach neu laden. In dem Fall werden die Tiles nicht neu angefordert werden müssen. Wie Frederik schon vorgeschlagen hat: Einmal Rendern und in ein Verzeichnis mit sauber eingestellten Cache-Anweisungen legen. (Default auf dem Server scheint bei maxage=10 Jahre zu liegen. Das sollte reichen) Und wenn man die Karte nicht bildschirmfüllend braucht, sondern sie zB in die Sidebar packt (unter Strecke), dann sollten auch 4 Tiles reichen. das heißt der client cacht die Tiles? Aber wenn ich F5 aukualisieren drücke hohlt er die doch neu, oder? Naja das die Tiels vorberechnet werden ist mir glasklar, alles was vorausberechnet werden kann wird auch vorrausberechnet um den Server freizuhalten zu Seiten auszuliefern und jede Verbindung die glücklich beendent ist verbraucht keinen Socket etc... Liebste grüße sandro ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Castorticker
Hi, Am 14. Dezember 2010 01:50 schrieb Hefee he...@netzguerilla.net: Naja in den letzten Tagen habe wir alle Bilder auf einen externen server gepackt, so das wir diese Last gar nicht mehr hatten... Wieviele Page Impressions pro Sekunde habt Ihr denn? Hier gehst Du davon aus, dass die Tiles nicht gecached werden. Ich glaube, das ist in der Regel falsch. Bei so einem Ticker werden viele Leute die Seite mehrfach neu laden. In dem Fall werden die Tiles nicht neu angefordert werden müssen. Wie Frederik schon vorgeschlagen hat: Einmal Rendern und in ein Verzeichnis mit sauber eingestellten Cache-Anweisungen legen. (Default auf dem Server scheint bei maxage=10 Jahre zu liegen. Das sollte reichen) Und wenn man die Karte nicht bildschirmfüllend braucht, sondern sie zB in die Sidebar packt (unter Strecke), dann sollten auch 4 Tiles reichen. das heißt der client cacht die Tiles? Aber wenn ich F5 aukualisieren drücke hohlt er die doch neu, oder? Bei einem normalen F5 sendet der Browser ein Get-if-modified-since, und der Server sagt ihm, dass sich das Objekt nicht geändert hat und die Kopie aus dem Browser-Cache genutzt werden kann. Anders ist das ganze, wenn man Ctrl-Shift-R drückt (FF), dann verlangt der Browser frische Objekte vom Server. Grüße, jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Idee für Image-Tool
Am 13.12.2010 16:53, schrieb Carsten Gerlach: Hallo, Am Montag 13 Dezember 2010 schrieb Jan Tappenbeck: Es wäre schön wenn über einen Algorithmus die Abgrenzung des Kontrastes geben könnte der diesen automatisch zeichnet oder zumindest dabei unterstützt. Du könntest versuchen, das Plugin = kann aber kein JS Gruß Jan :-) http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Lakewalker dahin gehend anzupassen. Gruß, Carsten -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Am 13.12.10 19:09, schrieb aighes: Da war ich etwas voreilig... Ich organisiere mir gerade beide Dateien von heute. Wie könnte man sie denn vergleichen? Dann könnte ich das morgen mal machen. Ich mach sowas mit WinMerge. Ich weiß allerdings nicht, ob das auch im Gigabytebereich noch tut. Mir fehlt es gerade an freiem Plattenplatz, um sowas zu testen... Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing und 4326
Am 13.12.10 17:46, schrieb geo.osm: Was ist denn der Grund dafür, dass Du verzerrte Bilder haben möchtest? Ich habe andere WMS-Services eingebunden, die nur WGS84 oder UTM zurückgeben. Und die würde ich gerne mit den Bing-Luftbildern überlagern. Das sind dann aber bestimmt keine Pixelbilder, sondern Vektordaten, oder? Umprojezierte Pixelbilder sehen nämlich ziemlich häßlich aus. So ähnlich wie mit WGS84 in josm erzeugte Häuser ;-) Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Hallo, meine Datei ist geringfügig kleiner: europe.osm.pbf von Geofabrik (13.12.2010): 9D278EE963925ED34701431B8573E0BF 4448335290 europe.osm.bz2 von Geofabrik (13.12.2010): CD8439ECFDB7E1012704C4CD6914ABB8 6567425820 europe.osm.pbf von mir (13.12.2010): C4186D9197225E97F5BC935BE09881E8 - 4448335278 Winmerge lasse ich mal drüberlaufen @Frederik: ein ftp wäre mir lieber. Viele Grüße, Henning -- View this message in context: http://gis.638310.n2.nabble.com/Problem-mit-osm-pbf-tp5808951p5833622.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 13.12.2010 16:17, schrieb aighes: Hallo, über die Suche kannst du dir alle geänderten Objekte markieren lassen. Evtl. musst du dann im Anschluss die Auswahl noch weiter eingrenzen... Du könntest dir natürlich auch ein Preset schreiben, was per Knopfdruck ein source=bing an das Objekt pappt. Das handhabe ich momentan so; so optimal ist mein Preset aber noch nicht und ganz glücklich bin ich mit der Lösung auch nicht. Netter wäre es imho, wenn z.B. beim Setzen von landuse=* automatisch ein source=Bing dazukommen könnte. schnipp Allgemein halte ich aber rcht wenig von source-Tag. Mitunter kann ein Objekt mehrere sourcen haben. soll man jetzt auch deshalb den Weg aussplitten? Oder gibt es dann auch unter-taggs wie amenity:source=*. Ich mappe Gebäude-Umrisse gern mit source:building=yes, insbesondere wenn ich bspw. Hausnummer und amenity=* bereits vorher ermittelt und source=survey gesetzt habe. Damit es nicht zu viel Getippe wird: Das Plugin building_tools bietet in den erweiterten Einstellungen die Möglichkeit, automatisch selbst gewählte Tags zu setzen, wenn man damit ein Gebäude zeichnet. Den Tipp habe ich im IRC aufgeschnappt und übernommen. schnapp Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Idee für Image-Tool
jan99 wrote: = kann aber kein JS Ist doch optimal, dann kannste ja direkt beginnen. Denn das Plugin ist in Java geschrieben. http://www.webmaster-eye.de/JavaScript-versus-Java-Der-Unterschied.359.artikel.html -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-Idee-fur-Image-Tool-tp5831076p5833692.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-in] Add myself to india category
Hey , I am beginner for this open street map and native of varanasi . even i didn't found the irc channel for OSM INDIA. So, could anyone tell me how to add myself in varanasi category. -- Amit Pal 3rd year Computer Science IT-BHU Varanasi,INDIA ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Add myself to india category
Hi Amit, Great to have you in OSM India. We don't have many mappers from your region. You could contribute a lot. Which Varanasi category are you referring about? Is it the wiki or something else? Regards, Vikas On 13 December 2010 23:46, Amit Pal amix@gmail.com wrote: Hey , I am beginner for this open street map and native of varanasi . even i didn't found the irc channel for OSM INDIA. So, could anyone tell me how to add myself in varanasi category. -- Amit Pal 3rd year Computer Science IT-BHU Varanasi,INDIA ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] Fusolab
2010/12/12 Fabri erfab...@gmail.com: La comunità osm di Roma è ufficialmente ospitata dall'associazione Fusolab durante le Domeniche Nerd ;) http://wiki.ninux.org/domenica%20nerd bene...quando vi vede segnalatelo con anticipo sul wiki (pagina italiana e internazionale) ciao Luca www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Fwd: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning
FYI... -- Forwarded message -- From: Grant Slater openstreet...@firefishy.com Date: Mon, Dec 13, 2010 at 15:24 Subject: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning To: Talk Openstreetmap t...@openstreetmap.org, annou...@openstreetmap.org OSM, Please copy this to local lists as appropriate. Tuesday 8:45am (14 December 2010 GMT/UTC+0) the API and editing on www.openstreetmap.org will be unavailable during hardware maintenance. The maintenance is expected to take 1 hour. Technical: Replacing a failed RAID Controller Battery. Regards Grant Part of the OSM Sysadmin Team ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Aiuto Linee del tram di Milano
Lavorando su una zona tra la Stazione Centrale e via Gioia ho ritenuto opportuno separare le due carreggiate di via Galvani nel tratto in cui attraversa piazza Duca d'Aosta. Anche se si tratta di un marciapiedi molto stretto, praticamente un salvagente, separa a tutti gli effetti i due sensi di marcia. Così facendo, però, mi sono imbattuto nell'editing delle linee del tram che passano da via Galvani. Ho notato che le vie sono inserite nella relazione route con ruolo forward o backward a seconda che il tram vada nello stesso senso in cui la way è stata disegnata oppure nel senso opposto. A parte il fatto che ho sempre pensato che forward/backward dovesse indicare che da quella way si passa quando si fa la route da A a B piuttosto che da B ad A... così facendo, come si gestisce il caso della doppia carreggiata?! In questo caso, Galvani nord (lato stazione, verso via Gioia) sarebbe forward, e Galvani sud (lato via Pisani, verso via Vitruvio) sarebbe backward... ma questo è in conflitto con la convenzione in uso. Chiedo conferma ai mapper milanesi, in particolare a chi si è occupato del trasporto pubblico. Per ora annullo lo split e lascio via Galvani untouched. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aiuto Linee del tram di Milano
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Simone Saviolo Sent: lunedì 13 dicembre 2010 16.10 To: openstreetmap list - italiano Subject: [Talk-it] Aiuto Linee del tram di Milano Ho notato che le vie sono inserite nella relazione route con ruolo forward o backward a seconda che il tram vada nello stesso senso in cui la way è stata disegnata oppure nel senso opposto. A parte il fatto che ho sempre pensato che forward/backward dovesse indicare che da quella way si passa quando si fa la route da A a B piuttosto che da B ad A... così facendo, come si gestisce il caso della doppia carreggiata?! In questo caso, Galvani nord (lato stazione, verso via Gioia) sarebbe forward, e Galvani sud (lato via Pisani, verso via Vitruvio) sarebbe backward... ma questo è in conflitto con la convenzione in uso. A Milano è stata inserita una relazione distinta per ciascun verso della route, dunque come hai osservato il ruolo forward/backward indica solo se la route va o meno nello stesso senso in cui è stata disegnata la via. Proprio perché si usano due relazioni completamente distinte per i due versi di percorrenza, non esiste il verso backward per la route. Se non ho capito male, dividendo le carreggiate (suppongo che ci sia una coppia di binari per ogni carreggiata) entrambi i tratti Galvani nord e Galvani sud avrebbero ruolo forward, ciascuno nella relazione che gli compete. Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: [OSM-talk] NOTICE: Scheduled Maintenance - Tuesday Morning
2010/12/13 Simone Cortesi sim...@cortesi.com Technical: Replacing a failed RAID Controller Battery. Ach! Diavolo d'un Berlusconi! :-D Scusate, ma non ho resistito -- Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Fountain o water ?
Ciao a tutti, volevo inserire alcune fontane (non fontanelle drink water)presenti in una piazza e ho usato il tag amenity:fountain. Mi sono accorto però che a livello di visualizzazione in openstreetmap queste non vengono visualizzate, ho controllato le famose fontane di Piazza Navona a Roma e ho visto che sono state inserite come natural:water e con l'aggiunta di un nodo esterno con il tag amenity:fountain. E' la procedura corretta ? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Situación en Atlántico
Las ciénagas y cuerpos de agua que se observan en ese punto son características naturales de esa zona http://www.openstreetmap.org/?lat=10.3559lon=-74.813zoom=14layers=M http://www.openstreetmap.org/?lat=10.3559lon=-74.813zoom=14layers=Mde hecho, la catástrofe guarda relación con los cambios a esa naturales hechos a principios del siglo pasado, con el objeto de enderezar el canal del dique, que pasó de cerca de 300 curvas a tener las 50 de hoy, esto ha incrementado la velocidad del caudal del canal, presionando con mayor fuerza sobre las riveras. Hace 13 años por medio de una resolución [0] y luego un Conpes [1], se le comisiona a Cormagdalena las obras para evitar lo que hoy está sucediendo. Solo hasta este año se han contratado las obras que aun no inician [2,3]. Se está trabajando por articularlos con los grupos de rescatistas para que usen los mapas que hemos actualmente desarrollado. Por favor *ayúdenos* es esa labor desde la Universidad Nacional, comunique que esto existe y que es útil para salvar vidas. Los mapas pueden ir insertados en GPS, la población puede ayudarnos a completar el mapa, ha identificar los puntos de mayor riesgo para el rompimiento de los diques. [0] http://bit.ly/h0zM2U [1] http://bit.ly/gBZkUx [2] http://bit.ly/euYqMA [3] http://bit.ly/hH8Gjc El 12 de diciembre de 2010 23:24, Luis Miguel Sánchez Zoque migueldesplazamientocen...@gmail.com escribió: En esta área cerca de Cantacallar, donde estuve mapeando un area innundada amplia, me parece encontrar un paso interrumpido, podrian ayudarme a confirmar que sea así, y como se puede hacer el tag? http://www.openstreetmap.org/edit?lat=10.355893lon=-74.810779zoom=18node=1030359853 Otra cosa: EN los videos del Rhok se destaca la brecha existente entre quienes estamos fuera de la zona y las necesidades en campo. Cuales serian las brechas en este momento con la zona afectada, pues no encontramos muchas actualizaciones o retroalimentación de los equipos de atención en Magdalena. Estoy en Bogotá, y creo que apoyando a la actividad de campo en esta zona con un contacto mñas directo de los equipos de rescate puede ayudar a mejorar la comunicación entre nosotros. Como lo ven ustedes? Gracias Luis Miguel Sánchez Zoque Sociólogo-UN Referente de Población Desplazada-GL E.S.E. Hospital Centro Oriente - Bogotá 3124725065 ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Situación en Atlántico
2010/12/12 Luis Miguel Sánchez Zoque migueldesplazamientocen...@gmail.com: En esta área cerca de Cantacallar, donde estuve mapeando un area innundada amplia, me parece encontrar un paso interrumpido, podrian ayudarme a confirmar que sea así, y como se puede hacer el tag? http://www.openstreetmap.org/edit?lat=10.355893lon=-74.810779zoom=18node=1030359853 Otra cosa: EN los videos del Rhok se destaca la brecha existente entre quienes estamos fuera de la zona y las necesidades en campo. Cuales serian las brechas en este momento con la zona afectada, pues no encontramos muchas actualizaciones o retroalimentación de los equipos de atención en Magdalena. Me comunican desde la zona: Carlos Andres Barrera 12 de diciembre de 2010 a las 20:24 Gracias por su ofrecimeinto Freddy, pero aqui la cartografia esta variando permanentemente. Ahora tenemos un gran embalse y los pueblos de la zona bajo el agua. Aqui, el mapa de Colombia literalmente cambió. Cualquier cosa te aviso. Esta brecha realmente es muy importante, necesitamos tener un equipo de verificación en la zona, sin embargo no contamos con los recursos económicos para hacerlo aunque si a maperos dispuestos a desplazarse, las labores de rescate y evacuación se realizan de forma azarosa, son pueblos que nunca han tenido mapa apoyados por rescatistas que nunca han tenido un GPS. No obstante nuestra labor como maperos se verá reflejada a futuro en el momento de la reconstrucciòn y apoyo. adelante! Estoy en Bogotá, y creo que apoyando a la actividad de campo en esta zona con un contacto mñas directo de los equipos de rescate puede ayudar a mejorar la comunicación entre nosotros. Como lo ven ustedes? Gracias Luis Miguel Sánchez Zoque Sociólogo-UN Referente de Población Desplazada-GL E.S.E. Hospital Centro Oriente - Bogotá 3124725065 ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
