Re: [OSM-talk-be] Power generation - tag update
On 07/02/2013 09:31 PM, Glenn Plas wrote:
http://overpass-turbo.eu/s/rA
Er is iets mis met de bovenstaande Overpass query, heb een iets simpele
versie nu, en die brengt toch wel veel meer werk naar boven nu.
union
query type=way into=waypower
has-kv k=power regv=power|station|generator/
bbox-query {{bbox}}/
/query
query type=area into=areapower
has-kv k=power regv=power|station|generator/
bbox-query {{bbox}}/
/query
query type=node into=nodepower
has-kv k=power regv=power|station|generator/
bbox-query {{bbox}}/
/query
/union
union
item/
recurse type=down/
/union
print mode=meta/
Best niet uitvoeren over meer dan 1 grote stad.
Mvg,
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Flyers
Ik kan wel zorgen voor een website. Ik heb het domein ivoweb.be en zou osm.ivoweb.be kunnen geven. Een eerste website (nog in opmaak, maar bereikbaar) is spain.ivoweb.be . Ik werk met Joomla . Op 4 juli 2013 16:19 schreef Ben Abelshausen ben.abelshau...@gmail.comhet volgende: Gegroet, Ik heb de flyer laten afdrukken zoals hij nu op github staat (100x). Voorlopig heb ik gewoon een link geplaatst naar de wiki-pagina voor Belgium. Misschien moeten wij ook met een paar mensen die interesse hebben eens een klein hack-weekendje organiseren en een simpele osm-be website bouwen. De flyer, maar dan online, zou al helpen denk ik zoals Martijn ook zegt. Of ziet iemand het zitten om dit alleen te doen? Ik ben spijtiggenoeg al een beetje overbelast als het OSM aankomt de laatste tijd anders zou ik zelf een poging wagen... Met vriendelijke groeten, Best regards, Ben Abelshausen ben.abelshau...@gmail.com http://twitter.com/xivk 2013/7/2 Martijn van Exel m...@rtijn.org Goed idee, maar uitsluitend als daar ook een levend(ig)e community van OpenStreetMappers aanwezig is. Wij gebruiken in de VS vrij actief Google+ (tot onvrede van sommigen, maar je kunt niet iedereen tevreden stellen). Elke twee weken hebben we bijvoorbeeld een Hangout waar iedereen welkom is. Een goede gelegenheid voor nieuwelingen om kennis te maken. )Indien ze een Google+ account hebben.) Een eigen website (hoe rudimentair ook) kan enorm behulpzaam zijn in dit geval, al was het maar om mensen door te verwijzen naar externe bronnen. 2013/7/2 Sander Deryckere sander...@gmail.com Misschien best om via de gekende sociale netwerken te gaan, deze hebben de laagste drempel en kunnen zeer goed dienen voor discussies. On 2 Jul 2013 19:43, Martijn van Exel m...@rtijn.org wrote: Is het forum actief in België? Dat zou een laagdrempelige manier kunnen zijn. Je kunt in elk geval de berichten lezen zonder in te schrijven, alhoewel je voor het plaatsen van een bericht wel een inschrijving nodig hebt. Anders weet ik ook niet zo gauw een beter alternatief voor Belgen (of Nederlanders) als 'eerste halte' voor contact met de community. help.osm.org is interessant, maar engelstalig en gericht op concrete vragen en antwoorden, niet op discussie en kennismaken. 2013/7/2 Ben Abelshausen ben.abelshau...@gmail.com Hallo, Goei punt over de mailinglijst! Zijn er andere suggesties over wat we op die flyer kunnen zetten voor beginnende mappers die hulp/contact willen? We hebben geen website voor osm-be. Het is ook belangrijk voor sommige mensen om geholpen te worden in de eigen taal. Ik heb mijn best gedaan hoge resolutie-versies te krijgen van bepaalde regio's. Ik zal eerst een paar proefdrukken doen alvorens er een paar honderd te laten drukken! :-) Met vriendelijke groeten, Best regards, Ben Abelshausen ben.abelshau...@gmail.com http://twitter.com/xivk 2013/7/2 Martijn van Exel m...@rtijn.org Ben, Prima idee! Twee dingen om even na te kijken wat mij betreft. Ten eerste zal een mailtje aan talk-be@ worden gebounced als men niet eerst inschrijft. Ten tweede, let op dat de kaart mooi afdrukt in hoge resolutie. Wat er fraai uitziet op het schem kan knullig aandoen op papier wanneer de afbeelding niet de juiste (hoge) resolutie heeft. Ik kijk uit naar het resultaat! Martijn 2013/7/2 Ben Abelshausen ben.abelshau...@gmail.com (In dutch because it's about the dutch-lanuage OSM-flyers :-) ) Hallo, Ik ga waarschijnlijk deze flyers laten afdrukken om eventueel te kunnen uitdelen op events/conferenties/hackweekends/etc... Ik heb ze dit weekend aangepast en heb nu de laatste versie op GitHub geplaatst: http://github.com/xivk/osm-flyer-dutch Jullie zouden mij een enorm plezier doen als jullie dit eens nakijken, commentaar op geven en te spell-checken! Ik zal zien hoeveel budget ik heb en hoeveel ik er daarmee kan afdrukken. Als jullie er nodig hebben, laat maar weten. Met vriendelijke groeten, Best regards, Ben Abelshausen ben.abelshau...@gmail.com http://twitter.com/xivk ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.us/ ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be --
[OSM-legal-talk] Elevation / SRTM data
Hi there, how would like to know how I could integrate SRTM data with OSM data. It is not for a mapping service where I could overlay the elevation curves/data and keep it separate. It is for my routing engine GraphHopper where I would need to do the following: * to calculate the distance I take the latitudes and longitudes from OSM, to guess the speed I take the highway and other tags. Then, with the help of the SRTM data I modify this distance and speed to be more real world. * to create an elevation profile of the resulting path. This should be simple (?) as the elevation data could be in a separate database and just fetched on demand. Will the resulting routing database fall under ODbL which the providers probably do not want as their elevation data could be guessed or even recalculated (with a bit effort)? Sorry, if this is a stupid question. I'm really new to OSM licensing world :) and there was a similar question but this was regarding hill shading and the old license: http://gis.19327.n5.nabble.com/OSM-legal-talk-ASTER-or-no-ASTER-td5715399.html Regards, Peter. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Elevation / SRTM data
If it's SRTM it's just public domain isn't it? So if the resulting database is under ODBL I can't see that being a problem. Very much IANAL. Nick -Peter K peat...@yahoo.de wrote: - To: legal-talk@openstreetmap.org From: Peter K peat...@yahoo.de Date: 04/07/2013 09:05AM Subject: [OSM-legal-talk] Elevation / SRTM data Hi there, how would like to know how I could integrate SRTM data with OSM data. It is not for a mapping service where I could overlay the elevation curves/data and keep it separate. It is for my routing engine GraphHopper where I would need to do the following: * to calculate the distance I take the latitudes and longitudes from OSM, to guess the speed I take the highway and other tags. Then, with the help of the SRTM data I modify this distance and speed to be more real world. * to create an elevation profile of the resulting path. This should be simple (?) as the elevation data could be in a separate database and just fetched on demand. Will the resulting routing database fall under ODbL which the providers probably do not want as their elevation data could be guessed or even recalculated (with a bit effort)? Sorry, if this is a stupid question. I'm really new to OSM licensing world :) and there was a similar question but this was regarding hill shading and the old license: http://gis.19327.n5.nabble.com/OSM-legal-talk-ASTER-or-no-ASTER-td5715399.html Regards, Peter. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Elevation / SRTM data
It is enhanced SRTM from cgiar: http://srtm.csi.cgiar.org/ E.g. see: http://srtm.csi.cgiar.org/SRTM_FAQ.asp - /Can I use this data for commercial use? //If interested in using this data for commercial purposes please email //Andy Jarvis mailto:a.jar...@cgiar.org//./ Regards, Peter. If it's SRTM it's just public domain isn't it? So if the resulting database is under ODBL I can't see that being a problem. Very much IANAL. Nick -Peter K peat...@yahoo.de wrote: - To: legal-talk@openstreetmap.org From: Peter K peat...@yahoo.de Date: 04/07/2013 09:05AM Subject: [OSM-legal-talk] Elevation / SRTM data Hi there, how would like to know how I could integrate SRTM data with OSM data. It is not for a mapping service where I could overlay the elevation curves/data and keep it separate. It is for my routing engine GraphHopper where I would need to do the following: * to calculate the distance I take the latitudes and longitudes from OSM, to guess the speed I take the highway and other tags. Then, with the help of the SRTM data I modify this distance and speed to be more real world. * to create an elevation profile of the resulting path. This should be simple (?) as the elevation data could be in a separate database and just fetched on demand. Will the resulting routing database fall under ODbL which the providers probably do not want as their elevation data could be guessed or even recalculated (with a bit effort)? Sorry, if this is a stupid question. I'm really new to OSM licensing world :) and there was a similar question but this was regarding hill shading and the old license: http://gis.19327.n5.nabble.com/OSM-legal-talk-ASTER-or-no-ASTER-td5715399.html Regards, Peter. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] OSM attributed by Korean firm Naver.
Hello everyone, I noticed recently that an OSM attribution has appeared at the bottom right on Korea's Naver mapping service. Naver is a Korean internet portal which is very popular here (er, in Korea). I don't know exactly what Naver is using OSM for, since I always assumed they acquired and maintained their own data (including their own streetview images). See the attribution for yourselves at: http://map.naver.com/ I don't know what you'll see, as Naver uses IP geolocation to estimate your starting position. Maybe outside Korea you'll be presented with Seoul. Another popular web portal is Daum. They have a map service (including streetview) but they don't acknowledge OSM, so they probably aren't using it: http://map.daum.net/?t__nil_bestservice=map Interesting? Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
Hi, Frederik Ramm frede...@remote.org wrote: http://fred.dev.openstreetmap.org/lowzoom/ I have updated these tiles with current data. (I had somehow lost the code that produced the tiles and had to reverse engineer my way back from the old tiles... the year-old tiles are still available from the layer switcher.) On 07/04/2013 02:00 AM, Tirkon wrote: I am not sure: Do you want to replace rhe lowzoom levels at osm.org? I think the lowzoom levels at osm.org look very bland and my approach attempts to fix that, trying not to be a cartographically solid map (for that, MapQuest has done an excellent job I think) but instead highlighting where OSM has data and where it hasn't. I don't have a particular agenda about replacing the lowzoom tiles on osm.org; if someone wants me to install my process on the OSM tile server I can do that but if most people are happy with what we've got then I have no problem with that. At present the shown names seem to be taken from the place tag. [...] The first priority for rendering could be the admin level. Certainly an idea worth pursuing, however some magic would have to be applied to match place tags (usually nodes - they will have a population or capital tag) with admininistrative boundaries (that have an admin level but neither capital nor population info). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Use of OSM data by UNEP without proper attribution
On Thursday 04 July 2013, Mikel Maron wrote: I just now have contact directly with those involved (relatively fast for a big organization), and am explaining the issue to them. Great, thanks for that. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Thursday 04 July 2013, Tirkon wrote: [...] The first priority for rendering could be the admin level. Within the admin level at first the towns with a capital tag are rendered wirh a star next to the name. If this is space-kompetitiv at a given zoom level, the winner will be decided on the population. Then all other towns of the given admin level are rendered. Space-competition is decided first on the place tag (which could indicate independent cities) and then on population. The problem about this is not how to do it in principle but that label placement optimization is a highly non-local problem so doing it well requires doing it for the whole globe at once and you would have to redo it every time something changes anywhere. Even the current very simple approach suffers from this problem resulting in occasional cut off labels at tile edges. The thing is the standard osm.org map is meant to allow near real time updates and compromises rendering quality for that. But there is very little actual real time data in the rendering at the lowest zoom levels anyway - none in 0 and 1, only labels in 2 and 3. Frederik's approach would bring the real time osm data to the lower zoom levels but in the end only few of the individual changes in the database have a visible effect on the map at this scale. So it would make sense to take a split approach to the lower zoom levels - create a real time version that allows reviewing edits made to the database and a second high quality version that is pre-rendered periodically using techniques that can be more expensive. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
2013/7/4 Frederik Ramm frede...@remote.org On 07/04/2013 02:00 AM, Tirkon wrote: I am not sure: Do you want to replace rhe lowzoom levels at osm.org? I think the lowzoom levels at osm.org look very bland and my approach attempts to fix that I partly agree (have thought that for a long time, but somehow got used to the status quo in the meantime). I believe they come from an era in OSM when we were still proud to have some country boundaries and the coastline (what we now take mostly for granted). , trying not to be a cartographically solid map (for that, MapQuest has done an excellent job I think) but instead highlighting where OSM has data and where it hasn't. yes, that's what makes them interesting, it is somehow osmarender lowzoom 2.0 ;-) (btw.: MapQuest seems to use a handmade map for really low zooms: 1-3) I don't have a particular agenda about replacing the lowzoom tiles on osm.org; if someone wants me to install my process on the OSM tile server I can do that but if most people are happy with what we've got then I have no problem with that. maybe we could have both? In the end low zoom tiles don't require so much disk space and won't have to be updated very often. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On 04/07/13 09:39, Christoph Hormann wrote: The thing is the standard osm.org map is meant to allow near real time updates and compromises rendering quality for that. But there is very little actual real time data in the rendering at the lowest zoom levels anyway - none in 0 and 1, only labels in 2 and 3. Low zooms (0 to 12) are not actually updated in real time anyway - they are only updated periodically by a batch job. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
Based on Frederik lowzoom idea, I started improving the low zooms on our OSM-FR style... Here is zoom 7 (others are in the render_list queue): http://tile.openstreetmap.fr/?zoom=7lat=46.88069lon=3.13697layers=B0FFF Here is how I did it: - modify my OSM-FR to remove all labels and boundary at zoom 8 (which was already using landcover/landuse), - generate 4 large PNG using nik2img - combine them and generate one large tiled z8.tif using gdal_translate (133MB, if you want to play with it I can share the result) - create a very simple stylesheet to test using this z8.tif as raster, then add placenames and boundaries It's a work in progress. I'm currently merging this lowzoom stylesheet to my main OSM-FR style sheet. I've not played with imagemagick, it is just a lanczos downscaling made by mapnik. Label ordering is handled by using the place=* tag, then the population=* tag so large cities are placed first. The placename density is limited using text-min-distance. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On Thursday 04 July 2013, Tom Hughes wrote: Low zooms (0 to 12) are not actually updated in real time anyway - they are only updated periodically by a batch job. But you can still trigger a rerender using /dirty. Greetings, -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
On 04/07/13 10:48, Christoph Hormann wrote: On Thursday 04 July 2013, Tom Hughes wrote: Low zooms (0 to 12) are not actually updated in real time anyway - they are only updated periodically by a batch job. But you can still trigger a rerender using /dirty. At the moment you probably can, yes. I have suggested a feature in mod_tile to tell it to never render tiles below a certain zoom though so that may not be true forever ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
Frederik Ramm frede...@remote.org wrote: The first priority for rendering could be the admin level. Certainly an idea worth pursuing, however some magic would have to be applied to match place tags (usually nodes - they will have a population or capital tag) with admininistrative boundaries (that have an admin level but neither capital nor population info). ÖK! So the idea could be slimmed down: No consideration of admin_level. Rendering as today decided on the place tag. But if there is much empty space the next lower value of the place tag will be used as well. No berücksichtigung Here is an example of empty space: http://www.openstreetmap.org/?lat=53.12lon=11.7zoom=8layers=M The other features could be added (possibly partly), because population and capital are now available. In particular preferred rendering of capital-names and its stars could be added for comparatively little costs. This alone gives a better orientation cause these cities are known better in the most cases. The magic in the extended version could be provided by adding the correspondent place-node with admin_centre-role as a member to the boundary-relation. But this has to be done worldwide and thus it is a problem. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
Am 04.07.2013 11:18, schrieb Christian Quest: Based on Frederik lowzoom idea, I started improving the low zooms on our OSM-FR style... Here is zoom 7 (others are in the render_list queue): http://tile.openstreetmap.fr/?zoom=7lat=46.88069lon=3.13697layers=B0FFF Here is how I did it: - modify my OSM-FR to remove all labels and boundary at zoom 8 (which was already using landcover/landuse), - generate 4 large PNG using nik2img - combine them and generate one large tiled z8.tif using gdal_translate (133MB, if you want to play with it I can share the result) - create a very simple stylesheet to test using this z8.tif as raster, then add placenames and boundaries It's a work in progress. I'm currently merging this lowzoom stylesheet to my main OSM-FR style sheet. I've not played with imagemagick, it is just a lanczos downscaling made by mapnik. Label ordering is handled by using the place=* tag, then the population=* tag so large cities are placed first. The placename density is limited using text-min-distance. Nice One minor problem: Some city names are not rendered but the city nodes. Probably it makes sense to allow to move label a bit if they are to close. Cheers colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapnik Lowzoom TIles - proof of concept
Am 04.07.2013 11:18, schrieb Christian Quest: Here is zoom 7 (others are in the render_list queue): to me this looks really nice and a huge improvement to the current OSM default lowzoom rendering! Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Would some wiki admin please move the page gluten_free=* back to proposal namespace
Hi I did move the page [1] a few days to proposal name space and started a discussion on its talk page [2]. On the same time we have a discussion about this issue on tagging@. Now with out discussion the page was reverted and I got following answer on my request to move it back [3]: I do not recognise the 'approval' process. I believe the wiki is for documenting tags as used. I do not propose to move this page back and will treat other attempts to move it as vandalism! Please, would some wiki admin move this page back to proposal name space and tell the user how to create page for new unused tags or tags with low usage and how communication works in OSM. I expect at least an apology for moving the page without any comment. Thanks colliar - [1] https://wiki.openstreetmap.org/wiki/Key:gluten_free [2] https://wiki.openstreetmap.org/w/index.php?title=Key:gluten_freeoldid=921090 [3] https://wiki.openstreetmap.org/wiki/User_talk:SK53 signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Would some wiki admin please move the page gluten_free=* back to proposal namespace
Hello, Have you noticed that there are many other people within OSM who think the wiki proposal system is completely broken and should be abolished/ignored? Look at the usernames at http://wiki.openstreetmap.org/wiki/Category:Users_against_tag_voting and try to find the osm admins on that list. On 07/04/2013 09:52 PM, colliar wrote: Hi I did move the page [1] a few days to proposal name space and started a discussion on its talk page [2]. On the same time we have a discussion about this issue on tagging@. Now with out discussion the page was reverted and I got following answer on my request to move it back [3]: I do not recognise the 'approval' process. I believe the wiki is for documenting tags as used. I do not propose to move this page back and will treat other attempts to move it as vandalism! Please, would some wiki admin move this page back to proposal name space and tell the user how to create page for new unused tags or tags with low usage and how communication works in OSM. I expect at least an apology for moving the page without any comment. Thanks colliar - [1] https://wiki.openstreetmap.org/wiki/Key:gluten_free [2] https://wiki.openstreetmap.org/w/index.php?title=Key:gluten_freeoldid=921090 [3] https://wiki.openstreetmap.org/wiki/User_talk:SK53 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- --- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New Scientist article on OpenStreetMap and HOT
Article at http://www.newscientist.com/article/dn23808-citizen-cartographers-fill-the-gaps-in-maps.html TomT5454 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Would some wiki admin please move the page gluten_free=* back to proposal namespace
No that is not beside the point at all. cuisine=vegetarian has 871 uses diet:vegetarian has 456 uses Because diet:... is approved people are suddenly allowed to write on both the cuisine page and the diet:... page that you shouldn't use cuisine=vegetarian? gluten_free=yes has 53 uses diet:gluten_free has 88 uses This insignificant difference suddenly lets you declare one key as controversial and hardly used? You can't play the numbers game only when it suits you and stay believable. Or maybe we should be grateful that the diet:... keys only contain one colon and just accept it :rolleyes: On 07/04/2013 10:47 PM, Tobias Knerr wrote: On 04.07.2013 22:15, Cartinus wrote: Have you noticed that there are many other people within OSM who think the wiki proposal system is completely broken and should be abolished/ignored? Yes, but that's beside the point. If that key was already widely used, then it would of course deserve a Key:* page without a proposal or vote. However, the key only has 53 uses and is also controversial, so I believe it should not yet be presented as if it were established. Moving this into the proposal namespace makes it clear that this is just an idea at this point, but lets people find it if they search for gluten free. It doesn't mean that it will necessarily ever go through an RFC, vote or whatever - it can also just sit there until it enough people have used it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- --- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Would some wiki admin please move the page gluten_free=* back to proposal namespace
On Thu, Jul 4, 2013 at 4:15 PM, Cartinus carti...@xs4all.nl wrote: Hello, Have you noticed that there are many other people within OSM who think the wiki proposal system is completely broken and should be abolished/ignored? It's not just the wiki proposal system, but the wiki users. They are often at odds with the actual tag usage and editing the wiki can become frustrating, as work is often reverted without discussion or review, simply because it does not follow a process that is not used by a vast majority of our users. In an ideal world, the tagging list would be a place where questions would be answers and things could be discussed like on talk, and wiki would reflect usage, but I suspect that the tagging weenies feel that they have a sort of power. - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Would some wiki admin please move the page gluten_free=* back to proposal namespace
On 04.07.2013 23:04, Cartinus wrote: gluten_free=yes has 53 uses diet:gluten_free has 88 uses This insignificant difference suddenly lets you declare one key as controversial and hardly used? The gluten_free key is controversial because there are many users who support a different key. It is hardly used because it only has 53 uses. The stats for diet:gluten_free did not play any role for my argument. You can't play the numbers game only when it suits you and stay believable. To me, proposals do matter (so diet:vegetarian from your examples would not be judged purely based on usage stats). I just don't consider it a requirement for considering a tag established. The proposal process is simply one of several valid approaches. As for gluten_free, why I'm even looking at the numbers here is because there has to be some proper reason for giving a key its own Key:* page. And gluten_free does not have an approved proposal, major tool support or anything like that, so the only thing left would be impressive taginfo stats - but it doesn't have much to offer in that department either. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Would some wiki admin please move the page gluten_free=* back to proposal namespace
That is a nice text where you admit that according to you the proposal system somehow magically grants wiki editors permission to vandalize other people's tag documentation and at the same time allows them to document hardly used but voted tags. For people who have missed why the voting system is broken. Here is a nice example: http://wiki.openstreetmap.org/wiki/Proposed_features/Designation On 07/04/2013 11:48 PM, Tobias Knerr wrote: On 04.07.2013 23:04, Cartinus wrote: gluten_free=yes has 53 uses diet:gluten_free has 88 uses This insignificant difference suddenly lets you declare one key as controversial and hardly used? The gluten_free key is controversial because there are many users who support a different key. It is hardly used because it only has 53 uses. The stats for diet:gluten_free did not play any role for my argument. You can't play the numbers game only when it suits you and stay believable. To me, proposals do matter (so diet:vegetarian from your examples would not be judged purely based on usage stats). I just don't consider it a requirement for considering a tag established. The proposal process is simply one of several valid approaches. As for gluten_free, why I'm even looking at the numbers here is because there has to be some proper reason for giving a key its own Key:* page. And gluten_free does not have an approved proposal, major tool support or anything like that, so the only thing left would be impressive taginfo stats - but it doesn't have much to offer in that department either. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- --- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Bitcoin-bijeenkomst bij stadscafé de Waag, Delft
Beste OSM'ers, Naar aanleiding van mijn oproep om bedrijven die Bitcoins aannemen vast te leggen in OpenStreetMap, tijdens Geo Freedom Day 2011: Tagging Bitcoin accepting businesses in OpenStreetMap http://www.youtube.com/watch?v=UjCCyNJ3DUU Deze zondag willen we samenkomen om wat te gaan drinken, en later op de dag wat te gaan eten, met andere Bitcoin- en Litecoin-gebruikers en geïnteresseerden om één uur 's middags in stadscafé de Waag in Delft (minder dan tien minuten lopen vanaf station Delft). Komen jullie ook? Zie: http://basdelange.com/bitcoin/index.html Help ons door je zelf op tijd op te geven bij ons? P.s. Volgende week zondag 14 juli willen we met Bitcoin en Litecoin-gebruikers samen komen in het Beurs van Berlage cafe paar minuten lopen vanaf station Amsterdam CS -- Learn programming, in your browser: http://tryrebol.esperconsultancy.nl Met vriendelijke groet, Best regards, Bas de Lange +31 (0)6 166 26 950 basdelange.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-br] Encontro em Porto Alegre
Em Qua, 2013-07-03 às 09:54 -0300, Samuel Vale escreveu: Em Qui, 2013-06-27 às 16:24 -0300, wille escreveu: Olá, Na próxima semana vai acontecer o FISL 14 em Porto Alegre. Samuel Vale vai dar uma palestra no dia 04: http://fisl.org.br/14/papers_ng/activity/view?activity_id=383 Eu ainda dependo de um detalhe para participar do FISL, mas tudo indica que estarei lá. Acho que seria uma boa oportunidade de organizarmos uma Mapping Party para estimular o surgimento de novos colaboradores ou pelo menos um encontro informal entre mapeadores. O que acham? Alguém que mora em PoA se anima? Abraços, Oi pessoal, Obrigado pela divulgação Wille :). Quem vai conduzir a atividade mesmo será o Frederico Goncalves Guimaraes freder...@teia.bio.br. Devido a um problema pessoal não poderei ir ao FISL este ano (infelizmente, estava até com passagens na mão :(). A atividade foi incluída da Grupo de Educação, então provavelmente muitos professores e profissionais da área participarão. Os colegas mapeadores que estiverem por lá estão convidados a aparecerem, sugiro até que entrem em contato com o Fred. Tivemos um pequeno encontro de última hora no FISL de 2010 e foi muito bom, com a presença de 5 contribuidores (ao menos). Abraço, Opa, Streaming da apresentação AGORA (04/07, 16:15h): http://hemingway.softwarelivre.org:8000/sala41d.ogg Abraço, -- Samuel Vale srcv...@minaslivre.org ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-de] Adressbestände Köln nun als OpenData
Anhand der NUTZUNG kann man aber in den meisten Fällen sicher auf ein building tag schließen. Hier ein group by NUTZUNG: 1013 - Reihenhaus 46169 1011 - Einzelhaus 26117 1015 - Wohnblock 25417 1012 - Doppelhaus 19367 1130 - Wohngebäude mit Gewerbe und Industrie 17212 1000 - Wohngebäude 5121 1120 - Wohngebäude mit Handel und Dienstleistungen 3072 9998 - Nach Quellenlage nicht zu spezifizieren 2144 2010 - Gebäude für Handel und Dienstleistungen 2006 2000 - Gebäude für Wirtschaft oder Gewerbe 899 3060 - Gebäude für soziale Zwecke 745 2110 - Produktionsgebäude 714 2120 - Werkstatt 710 1014 - Gruppenhaus 648 3100 - Gebäude für öffentliche Zwecke mit Wohnen 623 2020 - Bürogebäude 608 3041 - Kirche 520 2100 - Gebäude für Gewerbe und Industrie 403 3020 - Gebäude für Bildung und Forschung 379 2700 - Gebäude für Land- und Forstwirtschaft 375 2143 - Lagerhalle, Lagerschuppen, Lagerhaus 375 3000 - Gebäude für öffentliche Zwecke 361 2071 - Hotel, Motel, Pension 339 1016 - Hochhaus 263 2040 - Versicherung 220 3021 - Allgemein bildende Schule 201 1010 - Wohnhaus 156 2081 - Gaststätte, Restaurant 146 2030 - Kreditinstitut 139 2130 - Tankstelle 128 1022 - Seniorenheim 106 3001 - Verein, Verband 99 3210 - Gebäude für Sportzwecke 98 3030 - Gebäude für kulturelle Zwecke 97 1123 - Wohn- und Geschäftsgebäude 93 3050 - Gebäude für Gesundheitswesen 92 1100 - Gemischt genutztes Gebäude mit Wohnen 88 1020 - Wohnheim 86 2150 - Speditionsgebäude 83 3070 - Gebäude für Sicherheit und Ordnung 81 2200 - Sonstiges Gebäude für Gewerbe und Industrie 67 2460 - Gebäude zum Parken 58 3023 - Hochschulgebäude (Fachhochschule, Universität) 50 2090 - Freizeit- und Vergnügungsstätte 49 3065 - Kinderkrippe, Kindergarten, Kindertagesstätte 49 2540 - Gebäude für Fernmeldewesen 45 2720 - Land- und forstwirtschaftliches Betriebsgebäude 43 2620 - Gebäude zur Abfallbehandlung 41 3051 - Krankenhaus 35 2520 - Gebäude zur Elektrizitätsversorgung 34 2510 - Gebäude zur Wasserversorgung 32 2060 - Messehalle 30 2050 - Geschäftsgebäude 21 3022 - Berufsbildende Schule 18 3010 - Verwaltungsgebäude 18 2501 - Gebäude zur Energieversorgung 17 1122 - Wohn- und Bürogebäude 16 2160 - Gebäude für Forschungszwecke 14 2440 - Betriebsgebäude für Schiffsverkehr 13 3220 - Badegebäude 13 3080 - Friedhofsgebäude 12 3024 - Forschungsinstitut 12 3212 - Gebäude zum Sportplatz 11 2740 - Gewächshaus 9 1023 - Schwesternwohnheim 9 3034 - Museum 9 3052 - Heilanstalt, Pflegeanstalt, Pflegestation 8 2054 - Laden 8 2610 - Gebäude zur Abwasserbeseitigung 8 2052 - Einkaufszentrum 7 2463 - Garage 6 2590 - Gebäude zur Versorgungsanlage 6 2728 - Reithalle 6 3072 - Feuerwehr 6 1121 - Wohn- und Verwaltungsgebäude 5 1024 - Studenten-, Schülerwohnheim 5 3038 - Burg, Festung 5 1131 - Wohn- und Betriebsgebäude 5 2410 - Betriebsgebäude für Straßenverkehr 5 3260 - Gebäude im Zoo 4 2072 - Jugendherberge 4 3230 - Gebäude im Stadion 4 3015 - Gericht 4 2080 - Gebäude für Bewirtung 4 3223 - Gebäude im Kombibad 4 2131 - Waschstraße, Waschanlage, Waschhalle 3 3014 - Zollamt 3 3061 - Jugendfreizeitheim 3 1220 - Land- und forstwirtschaftliches Wohn- und Betriebsgebäude 3 3017 - Stadtverwaltung 3 3071 - Polizei 3 2070 - Gebäude für Beherbergung 3 3053 - Ärztehaus, Poliklinik 3 3032 - Theater, Oper 3 3062 - Freizeit-, Vereinsheim, Dorfgemeinschafts-, Bürgerhaus 3 2420 - Betriebsgebäude für Schienenverkehr 3 2461 - Parkhaus 3 3040 - Gebäude für religiöse Zwecke 3 3200 - Gebäude für Erholungszwecke 3 3091 - Bahnhofsgebäude 3 2074 - Campingplatzgebäude 2 2170 - Gebäude für Grundstoffgewinnung 2 2112 - Betriebsgebäude 2 2320 - Gebäude für Gewerbe und Industrie mit Wohnen 2 3044 - Gemeindehaus 2 2580 - Heizwerk 2 1022- Seniorenheim 2 3019 - Finanzamt 2 3064 - Obdachlosenheim 2 2180 - Gebäude für betriebliche Sozialeinrichtung 1 3281 - Schutzhütte 1 3036 - Veranstaltungsgebäude 1 3043 - Kapelle 1 2411 - Straßenmeisterei 1 2082 - Hütte (ohne Übernachtungsmöglichkeit) 1 3094 - Gebäude zum U-Bahnhof 1 3032 - Theater,Oper 1 2571 - Gaswerk 1 2083 - Kantine 1 2422 - Lokschuppen, Wagenhalle 1 3037 - Bibliothek, Bücherei 1 3090 - Empfangsgebäude 1 3270 - Gebäude im botanischen Garten 1 3033 - Konzertgebäude 1 2053 - Markthalle 1 2512 - Pumpstation 1 2055 - Kiosk 1 3042 - Synagoge 1 2111 - Fabrik 1 3211 - Sport-, Turnhalle 1 2421 - Bahnwärterhaus 1 2611 - Gebäude der Kläranlage 1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Adressbestände Köln nun als OpenData
Das ging wohl in die Hose 2. Versuch 46169 1013 - Reihenhaus 26117 1011 - Einzelhaus 25417 1015 - Wohnblock 19367 1012 - Doppelhaus 17212 1130 - Wohngebäude mit Gewerbe und Industrie 5121 1000 - Wohngebäude 3072 1120 - Wohngebäude mit Handel und Dienstleistungen 2144 9998 - Nach Quellenlage nicht zu spezifizieren 2006 2010 - Gebäude für Handel und Dienstleistungen 899 2000 - Gebäude für Wirtschaft oder Gewerbe 745 3060 - Gebäude für soziale Zwecke 714 2110 - Produktionsgebäude 710 2120 - Werkstatt 648 1014 - Gruppenhaus 623 3100 - Gebäude für öffentliche Zwecke mit Wohnen 608 2020 - Bürogebäude 520 3041 - Kirche 403 2100 - Gebäude für Gewerbe und Industrie 379 3020 - Gebäude für Bildung und Forschung 375 2700 - Gebäude für Land- und Forstwirtschaft 375 2143 - Lagerhalle, Lagerschuppen, Lagerhaus 361 3000 - Gebäude für öffentliche Zwecke 339 2071 - Hotel, Motel, Pension 263 1016 - Hochhaus 220 2040 - Versicherung 201 3021 - Allgemein bildende Schule 156 1010 - Wohnhaus 146 2081 - Gaststätte, Restaurant 139 2030 - Kreditinstitut 128 2130 - Tankstelle 106 1022 - Seniorenheim 99 3001 - Verein, Verband 98 3210 - Gebäude für Sportzwecke 97 3030 - Gebäude für kulturelle Zwecke 93 1123 - Wohn- und Geschäftsgebäude 92 3050 - Gebäude für Gesundheitswesen 88 1100 - Gemischt genutztes Gebäude mit Wohnen 86 1020 - Wohnheim 83 2150 - Speditionsgebäude 81 3070 - Gebäude für Sicherheit und Ordnung 67 2200 - Sonstiges Gebäude für Gewerbe und Industrie 58 2460 - Gebäude zum Parken 50 3023 - Hochschulgebäude (Fachhochschule, Universität) 49 2090 - Freizeit- und Vergnügungsstätte 49 3065 - Kinderkrippe, Kindergarten, Kindertagesstätte 45 2540 - Gebäude für Fernmeldewesen 43 2720 - Land- und forstwirtschaftliches Betriebsgebäude 41 2620 - Gebäude zur Abfallbehandlung 35 3051 - Krankenhaus 34 2520 - Gebäude zur Elektrizitätsversorgung 32 2510 - Gebäude zur Wasserversorgung 30 2060 - Messehalle 21 2050 - Geschäftsgebäude 18 3022 - Berufsbildende Schule 18 3010 - Verwaltungsgebäude 17 2501 - Gebäude zur Energieversorgung 16 1122 - Wohn- und Bürogebäude 14 2160 - Gebäude für Forschungszwecke 13 2440 - Betriebsgebäude für Schiffsverkehr 13 3220 - Badegebäude 12 3080 - Friedhofsgebäude 12 3024 - Forschungsinstitut 11 3212 - Gebäude zum Sportplatz 9 2740 - Gewächshaus 9 1023 - Schwesternwohnheim 9 3034 - Museum 8 3052 - Heilanstalt, Pflegeanstalt, Pflegestation 8 2054 - Laden 8 2610 - Gebäude zur Abwasserbeseitigung 7 2052 - Einkaufszentrum 6 2463 - Garage 6 2590 - Gebäude zur Versorgungsanlage 6 2728 - Reithalle 6 3072 - Feuerwehr 5 1121 - Wohn- und Verwaltungsgebäude 5 1024 - Studenten-, Schülerwohnheim 5 3038 - Burg, Festung 5 1131 - Wohn- und Betriebsgebäude 5 2410 - Betriebsgebäude für Straßenverkehr 4 3260 - Gebäude im Zoo 4 2072 - Jugendherberge 4 3230 - Gebäude im Stadion 4 3015 - Gericht 4 2080 - Gebäude für Bewirtung 4 3223 - Gebäude im Kombibad 3 2131 - Waschstraße, Waschanlage, Waschhalle 3 3014 - Zollamt 3 3061 - Jugendfreizeitheim 3 1220 - Land- und forstwirtschaftliches Wohn- und Betriebsgebäude 3 3017 - Stadtverwaltung 3 3071 - Polizei 3 2070 - Gebäude für Beherbergung 3 3053 - Ärztehaus, Poliklinik 3 3032 - Theater, Oper 3 3062 - Freizeit-, Vereinsheim, Dorfgemeinschafts-, Bürgerhaus 3 2420 - Betriebsgebäude für Schienenverkehr 3 2461 - Parkhaus 3 3040 - Gebäude für religiöse Zwecke 3 3200 - Gebäude für Erholungszwecke 3 3091 - Bahnhofsgebäude 2 2074 - Campingplatzgebäude 2 2170 - Gebäude für Grundstoffgewinnung 2 2112 - Betriebsgebäude 2 2320 - Gebäude für Gewerbe und Industrie mit Wohnen 2 3044 - Gemeindehaus 2 2580 - Heizwerk 2 1022- Seniorenheim 2 3019 - Finanzamt 2 3064 - Obdachlosenheim 1 2180 - Gebäude für betriebliche Sozialeinrichtung 1 3281 - Schutzhütte 1 3036 - Veranstaltungsgebäude 1 3043 - Kapelle 1 2411 - Straßenmeisterei 1 2082 - Hütte (ohne Übernachtungsmöglichkeit) 1 3094 - Gebäude zum U-Bahnhof 1 3032 - Theater,Oper 1 2571 - Gaswerk 1 2083 - Kantine 1 2422 - Lokschuppen, Wagenhalle 1 3037 - Bibliothek, Bücherei 1 3090 - Empfangsgebäude 1 3270 - Gebäude im botanischen Garten 1 3033 - Konzertgebäude 1 2053 - Markthalle 1 2512 - Pumpstation 1 2055 - Kiosk 1 3042 - Synagoge 1 2111 - Fabrik 1 3211 - Sport-, Turnhalle 1 2421 - Bahnwärterhaus 1 2611 - Gebäude der Kläranlage 1 3013 - Post ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Das ist nur zum Teil Nutzung, zum Teil sind es Gebäudetypologien, oder beides: Am 4. Juli 2013 08:10 schrieb jotpe jotpe@gmail.com: 46169 1013 - Reihenhaus - Typologie 26117 1011 - Einzelhaus - Typologie 25417 1015 - Wohnblock - Typologie 19367 1012 - Doppelhaus - Typologie 17212 1130 - Wohngebäude mit Gewerbe und Industrie - Nutzung, ggf. Typ 5121 1000 - Wohngebäude - Nutzung / Grober Typ 3072 1120 - Wohngebäude mit Handel und Dienstleistungen - Nutzung, grober Typ 2006 2010 - Gebäude für Handel und Dienstleistungen- grober Typ 899 2000 - Gebäude für Wirtschaft oder Gewerbe- grober Typ 745 3060 - Gebäude für soziale Zwecke- Nutzung 714 2110 - Produktionsgebäude - Typologie, Nutzung 710 2120 - Werkstatt - Typologie 648 1014 - Gruppenhaus - Typologie 623 3100 - Gebäude für öffentliche Zwecke mit Wohnen - Nutzung 608 2020 - Bürogebäude- grobe Typologie 520 3041 - Kirche - normalerweise Typologie, könnte aber auch Nutzung sein (Kirche in Wohngebäude z.B., dann wäre es aber keine Beschreibung des Gebäudes sondern der Einrichtung Kirche) ... Manche der Werte beschreiben ggf. nur eine Nutzung, andere sind klar Typen, z.B. Laden. Ein Laden bleibt z.B. auch dann ein Laden, wenn man darin wohnt (Ladenwohnung), d.h. er hat Schaufenster, liegt im EG, hat normalerweise entsprechende Lagerflächen, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Moin, Am 03.07.2013 14:05, schrieb Masi Master: Die StVO hat zwar eine andere Definition von Baulicher Trennung als wir bei OSM. gibt es für diesen (Fehl-)Satz eigentlich auch ein Hamburger Gerichtsurteil, dass er sich so sehr in den Köpfen festgesetzt hat? Die StVO definiert nirgends eine bauliche Trennung - und sie verwendet den Begriff auch nicht anders als OSM. Sie verwendet lediglich die Formulierung durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = bauliche Trennung wie bei OSM und grenzt ausdrücklich davon ab durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen 340) markiert. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 4. Juli 2013 10:56 schrieb Georg Feddern o...@bavarianmallet.de: Am 03.07.2013 14:05, schrieb Masi Master: Die StVO hat zwar eine andere Definition von Baulicher Trennung als wir bei OSM. Die StVO definiert nirgends eine bauliche Trennung - und sie verwendet den Begriff auch nicht anders als OSM. Sie verwendet lediglich die Formulierung durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = bauliche Trennung wie bei OSM und grenzt ausdrücklich davon ab durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen 340) markiert. in § 3 Abs 3, 2c StVO steht: ...Sie gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben 2xZ295 ist eine doppelte Mittellinie http://dejure.org/gesetze/StVO/3.html Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Adressbestände Köln nun als OpenData
Wir können auf der Wikiseite eine entsprechnde Überleit-Tabelle erstellen. NUTZUNG | building | amenity | etc Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Moin, Am 04.07.2013 11:05, schrieb Martin Koppenhoefer: Am 4. Juli 2013 10:56 schrieb Georg Feddern o...@bavarianmallet.de: Sie verwendet lediglich die Formulierung durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = bauliche Trennung wie bei OSM und grenzt ausdrücklich davon ab durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen 340) markiert. in § 3 Abs 3, 2c StVO steht: ...Sie gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben 2xZ295 ist eine doppelte Mittellinie http://dejure.org/gesetze/StVO/3.html hmm, stimmts Du mir jetzt zu oder hältst Du dagegen? Ist nicht so ganz eindeutig ... Aber genau darauf beziehe ich mich. OK, ich hätte die Quelle nochmal explizit angeben können, bin aber der Meinung StVO ist bereits eindeutig und die Fundstelle als Einzige ebenfalls: In § 3 Abs 3, 2c StVO findet sich folgender zusammenhängender Textblock: Diese Geschwindigkeitsbeschränkung gilt nicht auf Autobahnen (Zeichen 330.1) sowie auf anderen Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind. Sie gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben. Somit ist die doppelte Mittellinie eindeutig weder ein Mittelstreifen noch eine sonstige bauliche Einrichtung, sondern eben eine Markierung. Und somit hat die StVO kein anderes Verständnis einer baulichen Trennung als OSM. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
überprüfe bitte mal die einstellung deiner foren-software. hier kommt jeder reply von dir als neuer thread an. Gruss walter - [url=osm.wno-edv-service.de/residentials] Missing Residentials Map 1.13[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Adressbestande-Koln-nun-als-OpenData-tp5768236p5768245.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] Adressbestände Köln nun als OpenData
Foren-Software? Tja, der Schuster hat immer die schlechtesten Schuhe. Ich schreibe immer eine Mail an talk-de mit dem gleichen Betreff. Wie eine Mailingliste normalerweise geht, weiß ich, aber hier habe ich das nicht verstanden. Kann mir jemand erklären wie das richtig geht, oder sagen wo es steht? Danke. Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 4. Juli 2013 11:34 schrieb Georg Feddern o...@bavarianmallet.de: Somit ist die doppelte Mittellinie eindeutig weder ein Mittelstreifen noch eine sonstige bauliche Einrichtung, sondern eben eine Markierung. Und somit hat die StVO kein anderes Verständnis einer baulichen Trennung als OSM. ja, ich stimme Dir zu, eine doppelte Mittellinie ist keine bauliche Trennung, sie wirkt sich lediglich hinsichtlich der default Geschwindigkeitsbegrenzung gleich aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Gesetze der Realität, heute Numero drölf: bauliche Trennung ist baulich. Damit sollte das Ende der Diskussion doch wohl erreicht sein, oder? ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am Thu, 4 Jul 2013 12:54:30 +0200 schrieb jotpe jotpe@gmail.com: Ich schreibe immer eine Mail an talk-de mit dem gleichen Betreff. Der Betreff ist dafür nicht wichtig. Nimm bei der Mail auf die Du antworten willst den Antworten-Knopf statt eine neue Mail zu schreiben. Anders rum ist es genauso wichtig: Nicht den Antworten-Knopf nehmen, wenn es eine neue Mail sein soll. frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Adressbestände Köln nu als OpenData
Schon klar, dass man das so macht, aber ich bekomme nur 1x täglich eine Zusammenfassung aller eingegangen Mails auf talk-de. Und darauf kann man ja nicht antworten... Würde jede Mail einzeln reintrudel, wäre das ja gar kein Problem. Bekommst du alle Mails einzeln, oder kann ich das einschalten? Du sagtest Foren-Software, kann man damit bei dieser Mailingliste auch mitmachen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nu als OpenData
Am 4. Juli 2013 15:37 schrieb jotpe jotpe@gmail.com: Schon klar, dass man das so macht, aber ich bekomme nur 1x täglich eine Zusammenfassung aller eingegangen Mails auf talk-de. Und darauf kann man ja nicht antworten... ja, mit dem digest feature funktioniert die ML nicht richtig, das kannst Du in den Einstellungen ausmachen, hier ganz unten: http://lists.openstreetmap.org/listinfo/talk-de . Alternativ kann man online mitlesen und glaube auch antworten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
jotpe schrieb: Ich schreibe immer eine Mail an talk-de mit dem gleichen Betreff. Gut, das erklärt die ganzen neuen Threads. Einfach auf die MAil antworten, den Rest macht die Mailinglistensoftware. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-04T18:19:45+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
On 4 Jul 2013 10:37, Martin Koppenhoefer dieterdre...@gmail.com wrote: Das ist nur zum Teil Nutzung, zum Teil sind es Gebäudetypologien, oder beides: Dann haben die scheinbar genau das gleiche Definitionsproblem wir wir bei OSM. Gruß Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Georg Feddern o...@bavarianmallet.de wrote: Sie verwendet lediglich die Formulierung (a) durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = bauliche Trennung wie bei OSM und grenzt ausdrücklich davon ab (b) durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen 340) markiert. Ich hatte es schon einmal in diesem Thread versucht, zu erklären. Daher verdeutliche ich es noch einmal ausführlicher und anhand einer Zeichnung: (a) behandelt die Trennung der Richtungsfahrbahnen. (b) behandelt die Trennung der Fahrstreifen innerhalb einer Richtungsfahrbahn und nicht die Trennung der Richtungsfahrbahnen. Die in (b) erwähnten Leitlinien (gestrichelte Linie) werden niemals zur Richtungsfahrbahntrennung benutzt. Eine Trennung der Richtungsfahrbahnen durch Linien wird im §3 Abs.3 Nr.2c STVO(DE) nirgendwo explizit erwähnt. Von daher findet zwischen (a) und (b) auch keine Abgrenzung bezüglich der Richtungsfahrbahntrennung statt. (a) und (b) beziehen sich auf zwei unterschiedliche Dinge. _ ------ - - - - - - - - - - - - - - - - -(b) ------ _(a) _(a) ------ - - - - - - - - - - - - - - - - -(b) ------ _ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nu als OpenData
jotpe schrieb: Schon klar, dass man das so macht, aber ich bekomme nur 1x täglich eine Zusammenfassung aller eingegangen Mails auf talk-de. Und darauf kann man ja nicht antworten... Die Zusammenfassungsfunktion ist auch eher als Übersicht gedacht, und nicht zur aktiven Teilnahme. Würde jede Mail einzeln reintrudel, wäre das ja gar kein Problem. Melde dich auf deiner Verwaltungsseite [1] an, und stelle unter „Ihre persönlichen Einstellungen für Talk-de“ den „Zusammenfassungs Modus“ auf „Aus“ – Fertig. [1] http://lists.openstreetmap.org/options/talk-de/m...@example.com Wobei du m...@example.com durch deine für die Liste verwendete Mailadresse ersetzen musst. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-04T19:03:24+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 03.07.2013 23:55, schrieb Henning Scholland: Am 03.07.2013 23:14, schrieb Frederik Ramm: Hi, On 03.07.2013 22:44, jotpe wrote: unter http://wiki.openstreetmap.org/wiki/Cologne/Adressimport habe ich ein paar Infos für den manuellen Import zusammengestellt. Bitte nichts ueberstuerzen. Dass hier ueberhaupt ein Import stattfinden soll, ist noch ueberhaupt nicht diskutiert worden. Auf keinen Fall sollte irgendjemand hier einfach irgendwas hochladen. Meiner Meinung nach sollten Hausnummern auf jeden Fall mit bestehenden Gebaeuden verbunden (statt als Punkt irgendwo in oder neben ein Gebaeude hochgeladen) werden. Das koennte eventuell, mit grosser Vorsicht, automatisiert werden, in den USA hat jemand dafuer glaub ich mal ein Skript gebastelt. Wie wäre es mit folgender Variante: Man erstellt osm-Dateien mit den Hausnummern je Straße (bei langen Straßen evtl. auch mehrere) und Mapper mergen diese dann mit den vorhandenen Daten. +1 In D sollte es doch möglich sein, Hausnummern von nur einer Stadt auch manuell zu importieren. Wovon ich auch sehr abraten wuerde, ist das source-Tag an jedem Objekt. Das muellt die Datenbank unnoetig zu, und vorallem bleibt es aller Erfahrung nach auf Ewigkeiten da drin, auch wenn jemand den Node 3x verschiebt und 2x die Nummer korrigiert. Source-Tag am Changeset ist heute eigentlich der Standard. Oder? Sehe ich auch so. Vorallem da der Trend eher zu simplen Editoren geht, die dem Mapper nicht mehr unbedingt alle Tags anzeigt. Sodass der Mapper, der irgendwann einmal eine Hausnummer modifiziert wahrscheinlich gar nichts von dem source-Tag mit bekommt und in Folge dessen diesen auch nicht anpassen kann. +1 cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
On 04/lug/2013, at 18:34, Ronnie Soak chaoschaos0...@googlemail.com wrote: Dann haben die scheinbar genau das gleiche Definitionsproblem wir wir bei OSM. Im Prinzip sind es Typen, aber oft implizieren die auch eine Nutzung, insbesondere wenn sie noch der ursprünglichen Verwendungsbestimmung dienen. Wie anders genutzte Gebäude auftauchen (oder auch nicht) müsste ggf. der Herausgeber der Daten sagen können. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nu als OpenData
Super Dirk, das hat geholfen! Wusste gar nicht mehr, dass man da was einstellen konnte. Am 4. Juli 2013 19:12 schrieb Dirk Sohler s...@0x7be.de: jotpe schrieb: Schon klar, dass man das so macht, aber ich bekomme nur 1x täglich eine Zusammenfassung aller eingegangen Mails auf talk-de. Und darauf kann man ja nicht antworten... Die Zusammenfassungsfunktion ist auch eher als Übersicht gedacht, und nicht zur aktiven Teilnahme. Würde jede Mail einzeln reintrudel, wäre das ja gar kein Problem. Melde dich auf deiner Verwaltungsseite [1] an, und stelle unter „Ihre persönlichen Einstellungen für Talk-de“ den „Zusammenfassungs Modus“ auf „Aus“ – Fertig. [1] http://lists.openstreetmap.org/options/talk-de/m...@example.com Wobei du m...@example.com durch deine für die Liste verwendete Mailadresse ersetzen musst. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-04T19:03:24+0200 ___ 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] Adressbestände Köln nun als OpenData
Hallo, ich würde den Import nur da durchführen, wo bereits Gebäude gezeichnet wurden. Es fehlen noch viele und ich befürchte, irgendwann können wir nicht mehr stillschweigend die Aerowest Bilder weiter nutzen und daher mein dringender Appell, erstmal in Köln die Gebäude zu erfassen. Kann ja auch in einer Mischform von Häuserblock erfassen und dann alle Adressen zuordnen erfolgen. Viele Grüße Dietmar aka okilimu Am 04.07.2013 19:40, schrieb fly: Am 03.07.2013 23:55, schrieb Henning Scholland: Am 03.07.2013 23:14, schrieb Frederik Ramm: Hi, On 03.07.2013 22:44, jotpe wrote: unter http://wiki.openstreetmap.org/wiki/Cologne/Adressimport habe ich ein paar Infos für den manuellen Import zusammengestellt. Bitte nichts ueberstuerzen. Dass hier ueberhaupt ein Import stattfinden soll, ist noch ueberhaupt nicht diskutiert worden. Auf keinen Fall sollte irgendjemand hier einfach irgendwas hochladen. Meiner Meinung nach sollten Hausnummern auf jeden Fall mit bestehenden Gebaeuden verbunden (statt als Punkt irgendwo in oder neben ein Gebaeude hochgeladen) werden. Das koennte eventuell, mit grosser Vorsicht, automatisiert werden, in den USA hat jemand dafuer glaub ich mal ein Skript gebastelt. Wie wäre es mit folgender Variante: Man erstellt osm-Dateien mit den Hausnummern je Straße (bei langen Straßen evtl. auch mehrere) und Mapper mergen diese dann mit den vorhandenen Daten. +1 In D sollte es doch möglich sein, Hausnummern von nur einer Stadt auch manuell zu importieren. Wovon ich auch sehr abraten wuerde, ist das source-Tag an jedem Objekt. Das muellt die Datenbank unnoetig zu, und vorallem bleibt es aller Erfahrung nach auf Ewigkeiten da drin, auch wenn jemand den Node 3x verschiebt und 2x die Nummer korrigiert. Source-Tag am Changeset ist heute eigentlich der Standard. Oder? Sehe ich auch so. Vorallem da der Trend eher zu simplen Editoren geht, die dem Mapper nicht mehr unbedingt alle Tags anzeigt. Sodass der Mapper, der irgendwann einmal eine Hausnummer modifiziert wahrscheinlich gar nichts von dem source-Tag mit bekommt und in Folge dessen diesen auch nicht anpassen kann. +1 cu fly ___ 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] Adressbestände Köln nun als OpenData
Am 4. Juli 2013 19:40 schrieb fly lowfligh...@googlemail.com: +1 In D sollte es doch möglich sein, Hausnummern von nur einer Stadt auch manuell zu importieren. Sind zwar viele Hausnummer, dürfte aber im Bereich des Machbaren sein. Schätze in weniger gemappten Gebiete schafft man ein Stadtteil pro Abend, in der Stadtmitte, dürfte es was heftiger werden. Am 4. Juli 2013 19:40 schrieb fly lowfligh...@googlemail.com: Wovon ich auch sehr abraten wuerde, ist das source-Tag an jedem Objekt. Das muellt die Datenbank unnoetig zu, und vorallem bleibt es aller Erfahrung nach auf Ewigkeiten da drin, auch wenn jemand den Node 3x verschiebt und 2x die Nummer korrigiert. Source-Tag am Changeset ist heute eigentlich der Standard. Oder? Sehe ich auch so. Vorallem da der Trend eher zu simplen Editoren geht, die dem Mapper nicht mehr unbedingt alle Tags anzeigt. Sodass der Mapper, der irgendwann einmal eine Hausnummer modifiziert wahrscheinlich gar nichts von dem source-Tag mit bekommt und in Folge dessen diesen auch nicht anpassen kann. +1 Ich kann mich dem durchaus anschließen, dachte immer die Quelle eines Objektes bei Importen muss an das Objekt gepappt werden. Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 04.07.2013 21:27, schrieb jotpe: Am 4. Juli 2013 19:40 schrieb fly lowfligh...@googlemail.com: Hey Johannes Sind zwar viele Hausnummer, dürfte aber im Bereich des Machbaren sein. Schätze in weniger gemappten Gebiete schafft man ein Stadtteil pro Abend, in der Stadtmitte, dürfte es was heftiger werden. Na siehste, bei 20 Mapper_innen 2 Tage ? Ich kann mich dem durchaus anschließen, dachte immer die Quelle eines Objektes bei Importen muss an das Objekt gepappt werden. Ich weiß ja nicht wie Du genau vorgehst. Hast Du einen eigenen Benutzer für Importe ? Im Allgemeinen sollte es ausreichen, wenn Du mit Deinem Änderungssatz nur/größtenteils die Hausnummern importierst, dies dann im Änderungssatz so festzuhalten, mit anständigem Kommentare + source-Tag. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 4. Juli 2013 21:26 schrieb Dietmar ostr...@diesei.de: ich würde den Import nur da durchführen, wo bereits Gebäude gezeichnet wurden. Ich denke das alle Kölner das Ziel haben alle Gebäude mit Hausnummern einzuzeichnen. Aber das dauert eben sehr lange bei der geringen Anzahl aktiver Mapper. Erst alle Gebäude zu zeichnen und dann mit Adressdaten zu verbinden ist wahrscheinlich zu Mamutartig. Lieber erstmal die Adressen importieren und hinterher im Schneckentempo weiter Häuser drübermalen. Für meinen Teil benutze ich sehr häufig Adresssuche in OSM, all denjenigen wäre dann schonmal geholfen und nicht erst in 5 Jahren. Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 4. Juli 2013 21:35 schrieb fly lowfligh...@googlemail.com: Na siehste, bei 20 Mapper_innen 2 Tage ? Naja 86 Stadtteile.. Am 4. Juli 2013 21:35 schrieb fly lowfligh...@googlemail.com: Ich weiß ja nicht wie Du genau vorgehst. Hast Du einen eigenen Benutzer für Importe ? Achso, eigene Benutzer sind üblich? Wie ist das mit 20 Mappern? Passwortsharing? cheers ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 04.07.2013 21:57, schrieb jotpe: Am 4. Juli 2013 21:35 schrieb fly lowfligh...@googlemail.com: Na siehste, bei 20 Mapper_innen 2 Tage ? Naja 86 Stadtteile.. Sorry, war mir nicht bewußt das Köln so zersplittert ist, Aber innerhalb 2 Wochen immernoch gut machbar. Am 4. Juli 2013 21:35 schrieb fly lowfligh...@googlemail.com: Ich weiß ja nicht wie Du genau vorgehst. Hast Du einen eigenen Benutzer für Importe ? Achso, eigene Benutzer sind üblich? Wie ist das mit 20 Mappern? Passwortsharing? Da hast Du mich falsch verstanden: Wenn Du öfters importierst oder automatische Imports machst ist ein eigener zweiter Account wünschenswert bzw bei letzterem sogar Pflicht, damit man solche Änderungen von normalen Änderungen besser abgrenzen kann. So was wie die Hausnummern von Köln würde ich aber eher mit cadastre_fr gleich setzten und dann bleibt es Dir selber überlassen, ob Du unter Deinem normalen User oder einem anderem importieren willst. Colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 4. Juli 2013 21:50 schrieb jotpe jotpe@gmail.com: Für meinen Teil benutze ich sehr häufig Adresssuche in OSM, all denjenigen wäre dann schonmal geholfen und nicht erst in 5 Jahren. Die Adressen von grob 1,2% aller Menschen in Deutschland auf einen Schlag zu bekommen ist schon ein großer Sprung, ja! Wenn jetzt Berlin, Hamburg, München und Frankfurt nachziehen sind's sogar grob 10%. ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Hallo Jotpe, das Gebäude zeichnen ist ziemlich aufwändig, stimmt. Besonders viel Zeit geht aber verloren, wenn die schonmal in grober Form vorhanden sind (in Köln z.T. der Fall) und/oder wenn da dann dauernd die Adressknoten vorhanden sind. Die Gebäude können auch von Ortsunkundigen gezeichnet werden. Wie wäre es, wenn ein Aufruf gestartet wird, in Köln die Gebäude zu zeichnen, damit einigermaßen kurzfristig dann auch die Adressen ergänzt werden können? Es sieht, nebenbei bemerkt, in der osm.org Karte nicht gut aus, wenn da eine große Anzahl von Hausnummern pur vorkommen, aber keine Gebäude zu sehen sind. Unabhängig von der Vorgehensweise: für die Koordination des Hausnummernimports und/oder der Gebäude Zeichnerei könnte von Simon Poole der bereitgestellte rebuild Taskmanager [1] zur Koordinierung eingesetzt werden. Dort kann jeder sich ein Planquadrat auswählen (ich habe es eben probehalber erstellt und jede Task ist ca. 1.2 km2 groß, könnten wir noch feiner machen) und dann wäre ein koordiniertes Vorgehen möglich. Viele Grüße Dietmar aka okilimu [1] http://rebuild.poole.ch/ [2] http://rebuild.poole.ch/job/59 Am 04.07.2013 21:50, schrieb jotpe: Am 4. Juli 2013 21:26 schrieb Dietmar ostr...@diesei.de: ich würde den Import nur da durchführen, wo bereits Gebäude gezeichnet wurden. Ich denke das alle Kölner das Ziel haben alle Gebäude mit Hausnummern einzuzeichnen. Aber das dauert eben sehr lange bei der geringen Anzahl aktiver Mapper. Erst alle Gebäude zu zeichnen und dann mit Adressdaten zu verbinden ist wahrscheinlich zu Mamutartig. Lieber erstmal die Adressen importieren und hinterher im Schneckentempo weiter Häuser drübermalen. Für meinen Teil benutze ich sehr häufig Adresssuche in OSM, all denjenigen wäre dann schonmal geholfen und nicht erst in 5 Jahren. Gruß Johannes ___ 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] Adressbestände Köln nun als OpenData
Am 04.07.2013 22:42, schrieb Dietmar: Hey, das Gebäude zeichnen ist ziemlich aufwändig, stimmt. Ja, aber zB. der eXtruder Modus von JOSM wurde/wird gerade verbessert. Besonders viel Zeit geht aber verloren, wenn die schonmal in grober Form vorhanden sind (in Köln z.T. der Fall) und/oder wenn da dann dauernd die Adressknoten vorhanden sind. Dafür gibt es doch Werkzeuge. Zumindest für JOSM fallen mir da gleich einige ein. * Improve-way-Accuricy Modus * building-tool plugin * replaceGeometry aus utils2 plugin * conflation plugin. Die Gebäude können auch von Ortsunkundigen gezeichnet werden. Wie wäre es, wenn ein Aufruf gestartet wird, in Köln die Gebäude zu zeichnen, damit einigermaßen kurzfristig dann auch die Adressen ergänzt werden können? +1 Es sieht, nebenbei bemerkt, in der osm.org Karte nicht gut aus, wenn da eine große Anzahl von Hausnummern pur vorkommen, aber keine Gebäude zu sehen sind. Dann sieht mensch, dass noch was zu tun ist. Da stören mich die Häuser ohne Straßen in Frankreich schon eher. Unabhängig von der Vorgehensweise: für die Koordination des Hausnummernimports und/oder der Gebäude Zeichnerei könnte von Simon Poole der bereitgestellte rebuild Taskmanager [1] zur Koordinierung eingesetzt werden. Dort kann jeder sich ein Planquadrat auswählen (ich habe es eben probehalber erstellt und jede Task ist ca. 1.2 km2 groß, könnten wir noch feiner machen) und dann wäre ein koordiniertes Vorgehen möglich. +1 fly [1] http://rebuild.poole.ch/ [2] http://rebuild.poole.ch/job/59 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Hallo Trikon, Am Donnerstag, den 04.07.2013, 18:52 +0200 schrieb Tirkon: Georg Feddern o...@bavarianmallet.de wrote: Sie verwendet lediglich die Formulierung (a) durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = bauliche Trennung wie bei OSM und grenzt ausdrücklich davon ab (b) durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen 340) markiert. Ich hatte es schon einmal in diesem Thread versucht, zu erklären. Daher verdeutliche ich es noch einmal ausführlicher und anhand einer Zeichnung: (a) behandelt die Trennung der Richtungsfahrbahnen. (b) behandelt die Trennung der Fahrstreifen innerhalb einer Richtungsfahrbahn und nicht die Trennung der Richtungsfahrbahnen. Die in (b) erwähnten Leitlinien (gestrichelte Linie) werden niemals zur Richtungsfahrbahntrennung benutzt. Eine Trennung der Richtungsfahrbahnen durch Linien wird im §3 Abs.3 Nr.2c STVO(DE) nirgendwo explizit erwähnt. Von daher findet zwischen (a) und (b) auch keine Abgrenzung bezüglich der Richtungsfahrbahntrennung statt. (a) und (b) beziehen sich auf zwei unterschiedliche Dinge. Nein, eben nicht. Durch 295 oder durch 340 getrennt. Zeichen 295 ist definiert als die durchgehende Linie. (Anlage zur StVO, Zeichen 295) in 1b trennt sie den _Fahrbahnteil_ für den Gegenverkehr ab und nicht eine andere Fahrbahn. _ ------ - - - - - - - - - - - - - - - - -(b) ------ _(a) _(a) ------ - - - - - - - - - - - - - - - - -(b) ------ _ Bis auf dich scheinen alle (?) der Meinung zu sein, dass ein aufgemalter Strich kein Bauwerk ist und auch kein Bauwerk trennt, nicht baulich ist (a) != Bauliche Trennung (a) = 295 (b) = 340 (a) ~ (b) a und b haben im Wesentlichen die gleiche Bedeutung mit der Ausnahme, dass a nicht überfahren werden darf. a kann auch zwischen den Fahrspuren für die gleiche Richtung liegen. Dann ist es immer noch 295 Ebenso kann b in der Mitte sein. Dann ist es immer noch 340. Wenn (a) doppelt ist, ist (a) besser zu sehen. Den Zweiten sieht man besser. Außerdem spart man Farbe gegenüber einem ganz dicken Strich. Die Teile der Fahrbahn mit Gegenverkehr haben etwas mehr Abstand zueinander. Das ist alles. Eine weitere Bedeutung ist an keiner Stelle erkennbar. Weder wird die Geschwindigkeit tangiert, noch das Bauwerk. Sind die beiden Linien weiter voneinander entfernt, malt man da häufig noch schräge Striche zwischen. Das ist dann eine auf die Fahrbahn gemalte Sperrfläche. Baulich getrennt ist die Fahrbahn erst, wenn die Verkehrsinsel kommt, oder die Leitplanke oder ... (a) kann zusätzlich _Seiten_streifen abgrenzen. An der Seite, nicht in der Mitte. Gemeint ist z.B. der Radweg. Dann darf (a) überfahren werden, um Grundstückszufahrten oder Parkplätze zu erreichen. Auch da ist es aber eben keine bauliche Trennung. Wenn aber in der Mitte der Straße Grundstücke oder Parkplätze liegen sollten, würde ich das als bauliche Trennung durchgehen lassen ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Wolfgang Hinsch osm-lis...@ivkasogis.de wrote: Am Dienstag, den 02.07.2013, 19:28 +0200 schrieb Tirkon: Wolfgang Hinsch osm-lis...@ivkasogis.de wrote: Das ist deine Meinung, die Themen wie Verkehrssicherheit völlig außen vor lässt, ... Gerade bezogen auf die Verkehrssicherheit finde ich das Modell zweier gegenläufiger Einbahnstraßen suggestiver als einen Weg mit einer in der Karte nicht sichtbaren Relation, die das Umkehren verbietet. Hier bist du im Irrtum oder nicht auf dem Laufenden. Die Fahrspuren werden durch tags und nicht durch Relationen dargestellt. Ebenso die Mittellinie. Beschäftige dich mal mit dem Farspurmapping. http://wiki.openstreetmap.org/wiki/Key:lanes http://wiki.openstreetmap.org/wiki/DE:Key:turn http://wiki.openstreetmap.org/wiki/Key:change Es gibt Styles für josm, die das sichtbar machen. Da brat mir doch einer nen Storch. Das turn/lanes Konzept kenne ich und es gefällt mir, wie zuvor in diesem Thread schon erwähnt. Möglicherweise habe ich Tomaten auf den Augen. Aber nach meinem Verständnis gäbe es mit dem Sytem nur zwei Möglichkeiten, eine Doppellinie und damit eine Nichtnutzung der Gegenfahrbahn darzustellen: * Richtungsfahrbahnen als zwei getrennte gegenläufige Einbahnstraßen. ... willst Du nicht. * nur ein way, turn/lane Angaben getrennt nach forward und backward + UmkehrVerbots Relation (restriction=no_u_turn). ... Die Darstellung per Relation bezeichnest Du als Irrtum. Welche andere konkrete Lösung gibt es innerhalb des turn/lanes Konzeptes, die Situation der per Doppelstreifen getrennten Richtungsfahbahnen zu beschreiben - insbesondere eine solche, die so robust ist wie die beiden gegenläufigen Einbahnstraßen. Im übrigen fährt glücklicherweise immer noch der Fahrer das Auto, der das Navi während der Fahrt (eigentlich) nicht bedienen darf. Insofern ist es die _alleinige_ Entscheidung des Fahrers, ob er irgendwelchen Navi-Angaben folgt oder nicht. Verantwortung abschieben = Führerschein abgeben. Mögliche Folge beim Navi: Wenn möglich, bitte wenden. s.o. Wer Anweisungen des Navi im Zweifel nicht ignorieren kann, darf kein Navi benutzen oder sollte sich dringend nachschulen lassen. Es gib betreutes Wohnen, Essen, Ausflüge etc pp, aber betreutes Autofahren gibt es nicht. Natürlich hat der Fahrer die alleinige Verantwortung. Aber wieso erklärst Du mir das? Schließlich hast Du oben selbst das Thema fehlende Verkehrssicherheit meiner OSM Lösung der suggestiven und fehlertoleranten Darstellung des faktisch existierenden Einbahnstraßenverkehrs angeschnitten. Ich habe lediglich darauf geantwortet und das Gegenteil ausführlich belegt. Wenn dies zusätzlich zum Vorteil der eindeutigen Feststellbarkeit zu haben ist, die es beim Mittelstreifen wegen fehlender näherer Beschreibung nicht gibt, ist das doch keine Sünde. Alles in Allem hat das Einbahnstraßen-Modell wesentlich mehr Vorteile und ist zudem eindeutiger. Denn ob die Fahrbahnen faktisch zwischen zwei richtungsgetrennten Auf-/Abfahrten durchgehend richtungsgetrennt sind, kann eindeutig bestimmt werden. Dagegen ist die Definition eines Mittelstreifens umstritten. Sagst nur du. Ich habe noch keine Stelle gefunden, die einen oder zwei Striche als einen baulich getrennten Mittelstreifen definiert. Ich habe nirgendwo im Thread behauptet, dass die gemalten Streifen eine bauliche Trennung darstellen. Ich habe lediglich aufgeworfen, dass der in der STVO genannte Mittelstreifen nicht definiert und damit von jedem Mapper anders interpretierbar ist. Ich sehe da keine Erwähnung einer Bordsteinkante, keinen Grünstreifen, keine Leitplanke, keine aufgemalten Streifen - nichts davon. Damit ist der unterschiedlichen Interpretation durch Mapper Tür und Tor geöffnet, nicht mehr aber auch nicht weniger. Auf eine eindeutige bauliche Trennung hin zu mappen, ist ebenfalls verkehrsunsicherer. Denn bei einem Grünstreifen mit Leitplanke wechselt man nicht so schnell auf die Gegenfahrbahn, wie bei einer Trennung mit Doppelstreifen. Damit ist eine suggestivere Kennzeichnung im letzteren Fall noch angebrachter und damit verkehrssicherer. Das Wechseln auf die Gegenspur verhindert kein Navi. Es merkt es nicht mal. Noch mal: Der Fahrer fährt, und er und nur er hat die alleinige Verantwortung. Wenn er irgendetwas auf das Navi abschieben möchte, dokumentiert er, dass er sich ablenken ließ und hat sofort ein Problem. Siehe oben Der Mapper aber hat es wesentlich leichter, wenn einfach gilt: Durchgehender Asphalt ohne trennende Leitplanken o.ä. = eine Linie. Mittelstreifen mit Leitplanke, Betonmauer, Rasen, Büschen, wasAuchImmer = zwei Linien. Doppellinie = auch zwei Linien - ist genau so einfach für den Mapper. Wikipedia definiert einen Mittelstreifen sogar mit Mindestbreite von 2,5m + Hindernisse. Wo? Welche amtliche Quelle ist dafür angegeben? Einzelheiten wie Verkehrsfunktionalitäten sind ein Gebiet für die Fahrspuren und nicht ein Grund, die Fahrbahnen zu verbiegen. Ich fasse nochmals zusammen: Es geht hier um Straßen,
Re: [Talk-de] Bauliche Trennung
Wolfgang Hinsch osm-lis...@ivkasogis.de wrote: Am Donnerstag, den 04.07.2013, 18:52 +0200 schrieb Tirkon: Georg Feddern o...@bavarianmallet.de wrote: Sie verwendet lediglich die Formulierung (a) durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt = bauliche Trennung wie bei OSM und grenzt ausdrücklich davon ab (b) durch Fahrstreifenbegrenzung(Zeichen 295) oder durch Leitlinien (Zeichen 340) markiert. Ich hatte es schon einmal in diesem Thread versucht, zu erklären. Daher verdeutliche ich es noch einmal ausführlicher und anhand einer Zeichnung: (a) behandelt die Trennung der Richtungsfahrbahnen. (b) behandelt die Trennung der Fahrstreifen innerhalb einer Richtungsfahrbahn und nicht die Trennung der Richtungsfahrbahnen. Die in (b) erwähnten Leitlinien (gestrichelte Linie) werden niemals zur Richtungsfahrbahntrennung benutzt. Eine Trennung der Richtungsfahrbahnen durch Linien wird im §3 Abs.3 Nr.2c STVO(DE) nirgendwo explizit erwähnt. Von daher findet zwischen (a) und (b) auch keine Abgrenzung bezüglich der Richtungsfahrbahntrennung statt. (a) und (b) beziehen sich auf zwei unterschiedliche Dinge. Nein, eben nicht. Durch 295 oder durch 340 getrennt. getrennt ja ... aber nicht die Richtungsfahrbahnen, sondern die Fahrspuren innerhalb der Richtungsfahrbahnen. Bitte lies richtig! Sie (die Geschwindigkeitsbeschränkung PKW 100 km/h) gilt ferner nicht auf Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben. Bis auf dich scheinen alle (?) der Meinung zu sein, dass ein aufgemalter Strich kein Bauwerk ist und auch kein Bauwerk trennt, nicht baulich ist Ich habe das nirgendwo im Thread behauptet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-in] points to mark Indian Govt., offices
Hi Arun, On Thursday 04 July 2013 11:54 AM, Arun Ganesh wrote: I have been using amenity=public_building to mark public administrative offices. Also amenity=* + admin_level=* could be used to represent the administrative hierarchy of amenities like police, townhall, courthouse etc. Thanks for the response. But I couldn't find public_building inside Amenity when I collapsed it. I'm using Poltach 2(in-browser editor). Which one should I use to mark these offices.? Sorry, I'm bit new to OSM and started marking places from last few weeks. Thanks again, yogi ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] Correzione errori italia: domanda prima di operare pulizia sui nodi di way con tags
Tag ele: mi dicono che in Friuli sono frutto dei primi import CTRN. Credo che quelli da registrazioni GPX montane sia un dato utile visto che il campionamento SRTM è 90 metri e spesso ovoidale. -- http://cascafico.altervista.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappa per Garmin del Piemonte da dati CTRN e OSM
Hi group! I have published the development package for the CTRN-OSM-GPS map. This package contains all scripts and styles I wrote, plus some helpful bits like QGIS style files for the CTRN, and map icons. The package can be looked at and downloaded from this mercurial repository at bitbucket: https://bitbucket.org/kfj/ctrn-osm-gps-dev My method of converting ESRI shapefiles with ogr2osm into an intermediate representation in OSM format and then directly into a garmin map with mkgmap may interest other map-makers out there - so even if you're not from the Piedmont you may find the package interesting. It has taken me quite a while to figure out this technique, and it can be used for any ESRI shapefile (plus other OGR-compatible data sources), uses free tools only and is entirely script-driven. The use of free tools was especially important to me - this sector has a lot of software which isn't free, or has strings attached, or the free version is crippleware... I'm sure you know what I'm talking about. And to automate the whole conversion process, GUI-driven tools aren't the best choice, so doing everything with scripts is a nice solution :) I have previously been critisized for my licensing of the CTRN-OSM-GPS map (it's CC-BY-NC-SA), even though I feel it's an appropriate license and suitable for my combined work from several sources - see http://lists.openstreetmap.org/pipermail/talk-it/2012-November/031707.html I hope my publication shows that I do not intend to keep others from emulating my work and that I want to bring forward the use of open data. Yet again, please forgive me for posting in english; if anyone feels like translating this posting, please do so, and thanks in advance! Kay ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import delle biblioteche italiane
Il 04/07/2013 09:50, Luca Delucchi ha scritto: 2013/7/2 Maurizio Napolitanonapoo...@gmail.com: Molte di queste biblioteche hanno i dati relativi alle coordinate. Pensavo quindi di fare un import di questi dati dentro OSM. Prima è meglio se estrai tutte le biblioteche che sono presenti in OpenStreetMap. Penso che molte siano già inserite e, addirittura, come edificio. No sono tantissime (su un dataset che ho del 24 maggio ne ho contate 1.121) +1 per quelle che già trovi basta aggiornare i dati presenti Potresti anche pensare di scrivere una nota[1] per ogni biblioteca, con dentro tutti i dati che hai trovato, più un messaggio del tipo: Verificare che tutti questi dati siano già presenti; in alternativa li si aggiunga. In questo modo si evita di fare un import automatico, e si fornirebbe un aiuto ai mappatori locali. È un po' quello che voglio fare per i negozi che accettano Bitcoin; potremmo unire gli sforzi. Il primo ostacolo che ho trovato è questo[2], volendo fare tutto con uno script Python. Ciao! Carlo [1] http://wiki.openstreetmap.org/wiki/Notes [2] https://github.com/xificurk/osmapis/issues/1 -- .-. | Registered Linux User #443882| .''`. oo| | http://linuxcounter.net/ | : :' : /`'\ | Registered Debian User #9 | `. `'` (\_;/) | http://debiancounter.altervista.org/ | `- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Open data pavia e wiki
2013/7/4 Daniele Forsi dfo...@gmail.com: molto bene, l'ho assimilato per il confronto degli stradari http://www.forsi.it/osm/spellcheck/highway/stradario/Pavia/ 260 nomi sono solo in OSM, 470 solo nei dati del Comune e 299 sono in entrambi grazie. ogni quanto aggiorni? stranamente OSM ha le tangenziali Est e Nord mentre il comune ha le tangenziali Est e Ovest osm è corretto secondo i cartelli stradali -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tmc in italia - cciss
2013/7/3 girarsi_liste liste.gira...@gmail.com: i dati di traffico dinamici, che cambiano ogni minuto, non vanno inserite in osm. Ignoro la cosa, magari mi dai un link, magari su wikipedia, dove possa farmi un'idea della cosa? mappe non ne ho trovate, posso darti un link generico a wikipedia: http://en.wikipedia.org/wiki/Traffic_message_channel -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Correzione errori italia: domanda prima di operare pulizia sui nodi di way con tags
2013/7/4 Cascafico Giovanni cascaf...@gmail.com Tag ele: mi dicono che in Friuli sono frutto dei primi import CTRN. Credo che quelli da registrazioni GPX montane sia un dato utile visto che il campionamento SRTM è 90 metri e spesso ovoidale. Se non disponi di un GPS con sensori barometrici (e se non hai calibrato questi sensori poche ore prima con un dato affidabile), la qualità altimetrica del segnale GPS è pessima (ca. 10 volte meno preciso della posizione orizzontale). Per calibrare si deve stare attento al sistema di riferimento, cosa spesso non è ne anche così facile (perché non esplicitato). In OSM usiamo WGS84 come sistema di riferimento, ma i valori che si leggono sui cartelli in Italia al solito sono in un altro sistema. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tmc in italia - cciss
Non si aggiorna più :( Gli ho scritto una mail affinchè sistemino Il 03/07/2013 19:19, Simone Cortesi ha scritto: Si possono importare anche questi dati? http://www.opendata.provincia.roma.it/dataset/monitoraggio-traffico-stradale/resource/02f0cd9e-642c-40ba-a1d2-e72c9767f471 io non vedo nulla. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Interessante il link. Fa un esempio che potrebbe esser utile, per definire le aree landuse usa le linee delle strade, invece di crearsi delle aree a doc, certo che così bisogna spezzare le way in una marea di pezzetti e creare delle relazioni. Che ne dite? -- View this message in context: http://gis.19327.n5.nabble.com/landuse-tp5766839p5768241.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Il giorno 04 luglio 2013 11:48, bredy bredy...@yahoo.it ha scritto: Interessante il link. Fa un esempio che potrebbe esser utile, per definire le aree landuse usa le linee delle strade, invece di crearsi delle aree a doc, certo che così bisogna spezzare le way in una marea di pezzetti e creare delle relazioni. Che ne dite? Dico NO, in maiuscolo, grassetto e corpo 72 :-) Riusare le way delle strade per i landuse è una cattiva idea per svariati motivi. Ricorderò solo la difficoltà nell'editing successivo e l'errore formale derivante dal fatto che le strade hanno una larghezza che non viene rappresentata dalla sola way. Disegna i landuse dove si trovano. È più corretto, bello e facile da mantenere. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Correzione errori italia: domanda prima di operare pulizia sui nodi di way con tags
Il giorno 03 luglio 2013 23:31, Mario Pichetti mario.piche...@gmail.comha scritto: Il 03/07/2013 22:39, marco bra ha scritto: ... https://wiki.openstreetmap.org/wiki/IT:Quality_Assurance_Tools_script/Installation Con win7 non si riesce ad aggiungere /jython-standalone-2.5.3.jar!/ Per aggiungere il file devi fare clic sul pulsante Aggiungi e poi doppio click sulla riga vuota che compare. Ciao, Groppo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Dunque, se metti solo il tag cycleway:right=lane o cycleway:left=lane non viene renderizzato nulla. Se ci aggiungi anche il tag cycleway=lane viene renderizzata su OCM con due striscette blu ai lati e anche su josm la strada assume un colore diverso. In effetti bisognerebbe chiarire qual'è la maniera esatta di taggare la sola corsia ciclabile su un lato , o corsie su entrambi i lati. Con un tag o due. Purtroppo al momento la OCM non permette di distinguere se ce ne sono su entrambi i lati (doppio senso) o su un lato solo. Mette solo delle lineette blu per segnalare che c'è, ma non da informazioni su dove. Ps: stiamo parlando di una strada con una corsia ciclabile delimitata da una striscia di vernice, e non di una pista ciclabile in sede separata Il 29/06/2013 12:09, bredy ha scritto: Se taggo le strade con una ciclabile contigua (lane) su un solo lato, poi in OpenCicleMap questa non viene visualizzata, mentre quando è su entrambe i lati si. Sbaglio ad usare il tag o OCM non supporta ancora il riconoscimento del tag su un solo lato? -- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Correzione errori italia: domanda prima di operare pulizia sui nodi di way con tags
Intanto scusate: quel ovoidale, frutto del correttore, è un void (assenza di dati) normalmente causati da pareti particolarmente ripide oppure da neve, entrambi problematici per le registrazioni srtm Sulla precisione Z, personalmente non ho notato errori oltre gli 1-3 metri nei punti noti che frequento (garmin nuvi ed huawei ideos) che, rispetto ai void o interpolazione sui 90m, mi sembrano trascurabili. Forse il problema montano più comune è il fogliame. Vedrò di farci caso. Comunque non ho mai caricato in osm direttamente gpx, tantomeno con ele, che in JOSM preclude la semplificazione -- http://cascafico.altervista.org Il giorno 04/lug/2013 10.59, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2013/7/4 Cascafico Giovanni cascaf...@gmail.com Tag ele: mi dicono che in Friuli sono frutto dei primi import CTRN. Credo che quelli da registrazioni GPX montane sia un dato utile visto che il campionamento SRTM è 90 metri e spesso ovoidale. Se non disponi di un GPS con sensori barometrici (e se non hai calibrato questi sensori poche ore prima con un dato affidabile), la qualità altimetrica del segnale GPS è pessima (ca. 10 volte meno preciso della posizione orizzontale). Per calibrare si deve stare attento al sistema di riferimento, cosa spesso non è ne anche così facile (perché non esplicitato). In OSM usiamo WGS84 come sistema di riferimento, ma i valori che si leggono sui cartelli in Italia al solito sono in un altro sistema. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
On 04/lug/2013, at 11:55, Simone Saviolo simone.savi...@gmail.com wrote: Disegna i landuse dove si trovano. È più corretto, bello e facile da mantenere. +1 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Il 07/04/2013 12:07 PM, Fabri scrisse: In effetti bisognerebbe chiarire qual'è la maniera esatta di taggare la sola corsia ciclabile su un lato , o corsie su entrambi i lati. Con un tag o due. Purtroppo al momento la OCM non permette di distinguere se ce ne sono su entrambi i lati (doppio senso) o su un lato solo. Mette solo delle lineette blu per segnalare che c'è, ma non da informazioni su dove. La maniera corretta di taggare e' quella indicata sul wiki. Il fatto che OCM abbia deciso di non gestire in maniera appropriata questi tag puo' dipendere da tanti motivi (pochi casi, rendering poco chiaro, mancanza di motivazione del gestore di OCM) ma il tagging non va fatto solo in funzione del rendering. I tag vengono usati anche per fare routing o per mappe diverse da OCM. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Correzione errori italia: domanda prima di operare pulizia sui nodi di way con tags
Per la zona in oggetto http://www.openstreetmap.org/?lat=44.48514lon=11.31156zoom=16 ho tolto tutti i tag name che contenevano semplicemente il progressivo del punto dai nodi delle tracce... ed anche alcuni nodi orfani. Ho contattato l'utente che aveva importato tali tracce. Il tag ele nei nodi di eventuali tracce quando li troverò non li leverò. Grazie cordialmente mcheck Il 04 luglio 2013 12:22, Cascafico Giovanni cascaf...@gmail.com ha scritto: Intanto scusate: quel ovoidale, frutto del correttore, è un void (assenza di dati) normalmente causati da pareti particolarmente ripide oppure da neve, entrambi problematici per le registrazioni srtm Sulla precisione Z, personalmente non ho notato errori oltre gli 1-3 metri nei punti noti che frequento (garmin nuvi ed huawei ideos) che, rispetto ai void o interpolazione sui 90m, mi sembrano trascurabili. Forse il problema montano più comune è il fogliame. Vedrò di farci caso. Comunque non ho mai caricato in osm direttamente gpx, tantomeno con ele, che in JOSM preclude la semplificazione -- http://cascafico.altervista.org Il giorno 04/lug/2013 10.59, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2013/7/4 Cascafico Giovanni cascaf...@gmail.com Tag ele: mi dicono che in Friuli sono frutto dei primi import CTRN. Credo che quelli da registrazioni GPX montane sia un dato utile visto che il campionamento SRTM è 90 metri e spesso ovoidale. Se non disponi di un GPS con sensori barometrici (e se non hai calibrato questi sensori poche ore prima con un dato affidabile), la qualità altimetrica del segnale GPS è pessima (ca. 10 volte meno preciso della posizione orizzontale). Per calibrare si deve stare attento al sistema di riferimento, cosa spesso non è ne anche così facile (perché non esplicitato). In OSM usiamo WGS84 come sistema di riferimento, ma i valori che si leggono sui cartelli in Italia al solito sono in un altro sistema. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Linux Infinite Freedom I'm writing from this place: http://www.openstreetmap.org/?lat=44.39945lon=8.6798zoom=15layers=M ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
vedi L1a, L1b, L2 sulle pagine https://wiki.openstreetmap.org/wiki/Bicyclee https://wiki.openstreetmap.org/wiki/IT:Bicycle PS: secondo me la foto per L2 nel wiki è sbagliata. Mostra una pista ciclabile separata dalla strada. Sono chiaramente visibili dei blocchi in cemento che rendono difficile l'attraversamento. Io avrei taggato questa sitazione come T2 Volker 2013/7/4 emmexx emm...@tiscalinet.it Il 07/04/2013 12:07 PM, Fabri scrisse: In effetti bisognerebbe chiarire qual'è la maniera esatta di taggare la sola corsia ciclabile su un lato , o corsie su entrambi i lati. Con un tag o due. Purtroppo al momento la OCM non permette di distinguere se ce ne sono su entrambi i lati (doppio senso) o su un lato solo. Mette solo delle lineette blu per segnalare che c'è, ma non da informazioni su dove. La maniera corretta di taggare e' quella indicata sul wiki. Il fatto che OCM abbia deciso di non gestire in maniera appropriata questi tag puo' dipendere da tanti motivi (pochi casi, rendering poco chiaro, mancanza di motivazione del gestore di OCM) ma il tagging non va fatto solo in funzione del rendering. I tag vengono usati anche per fare routing o per mappe diverse da OCM. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Domanda su accessi ciclabili nel forum
Per le strade private dipende da caso a caso, per esempio guarda qua http://www.flickr.com/photos/76225195@N07/9205395693/ In questo caso è solamente vietata la sosta. In altri casi la sosta e il transito, ma principalmente di autovetture. Quella in foto è un service, non metterei access=private, quello lo metterei nel vialetto al di là del cancello che si vede. ci sono tante strade cosidette private, che sono usate normalmente da pedoni. se è vietato il transito di solito metto qualcosa tipo motor_vehicle=private. inoltre access=private esclude la via dalla ricerca su alcuni navigatori Per il divieto di accesso non ho approfondito il CdS, ma ad esempio questo: http://www.flickr.com/photos/76225195@N07/9208259618/ vieta l'accesso a chiunque o solo ai motoveicoli esclusi i mezzi di soccorso? la strada è pedonale... On 29/giu/2013, at 14:22, Elena ``of Valhalla'' elena.valha...@gmail.com wrote: a parte quello, di solito il divieto di accesso è effettivamente per tutti (salvo chi deve raggiungere la proprietà), solo che da un lato in italia è estremamente raro veder fare una multa a pedoni o bici, dall'altro di solito i proprietari sono tolleranti nei confronti di chi passa senza dare fastidio. I pattini (da codice della strada) non si potrebbero usare del tutto sulle strade / marciapiedi / piste pedonali, per cui non si pone il problema, ma anche lì non ho mai visto fare multe. Su osm io mapperei come access = private, foot = permissive, bicycle = permissive (no, non semplicemente access = permissive, motor_vehicle = private: in media non credo proprio che accettino ad esempio il passaggio con un cavallo) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
correzione del PS: La foto per L1b mi sembra sbagliata ... Scusate l'errore Volker 2013/7/4 Volker Schmidt vosc...@gmail.com vedi L1a, L1b, L2 sulle pagine https://wiki.openstreetmap.org/wiki/Bicyclee https://wiki.openstreetmap.org/wiki/IT:Bicycle PS: secondo me la foto per L2 nel wiki è sbagliata. Mostra una pista ciclabile separata dalla strada. Sono chiaramente visibili dei blocchi in cemento che rendono difficile l'attraversamento. Io avrei taggato questa sitazione come T2 Volker 2013/7/4 emmexx emm...@tiscalinet.it Il 07/04/2013 12:07 PM, Fabri scrisse: In effetti bisognerebbe chiarire qual'è la maniera esatta di taggare la sola corsia ciclabile su un lato , o corsie su entrambi i lati. Con un tag o due. Purtroppo al momento la OCM non permette di distinguere se ce ne sono su entrambi i lati (doppio senso) o su un lato solo. Mette solo delle lineette blu per segnalare che c'è, ma non da informazioni su dove. La maniera corretta di taggare e' quella indicata sul wiki. Il fatto che OCM abbia deciso di non gestire in maniera appropriata questi tag puo' dipendere da tanti motivi (pochi casi, rendering poco chiaro, mancanza di motivazione del gestore di OCM) ma il tagging non va fatto solo in funzione del rendering. I tag vengono usati anche per fare routing o per mappe diverse da OCM. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Domanda su accessi ciclabili nel forum
2013/7/4 Fabri erfab...@gmail.com Per il divieto di accesso non ho approfondito il CdS, ma ad esempio questo: http://www.flickr.com/photos/76225195@N07/9208259618/ vieta l'accesso a chiunque o solo ai motoveicoli esclusi i mezzi di soccorso? il segno vieta l'accesso a tutti i veicoli (ma solo veicoli), i mezzi di soccorso quando hanno esigenza possono fare qualsiasi cosa ragionevole (credo), quindi è un po' superfluo quel cartello. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Il 07/04/2013 12:50 PM, Volker Schmidt scrisse: PS: secondo me la foto per L2 nel wiki è sbagliata. Mostra una pista ciclabile separata dalla strada. Sono chiaramente visibili dei blocchi in cemento che rendono difficile l'attraversamento. Io avrei taggato questa sitazione come T2 Secondo me i blocchi non sono in cemento e mi pare anche abbastanza semplice passare dalla ciclabile alla strada. Cioe' la separazione fisica non e' abbastanza marcata da far pensare al caso T2. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Guardando meglio, penso addiritura che le foto per L1b e T2 sono state intercambiate. Volker 2013/7/4 emmexx emm...@tiscalinet.it Il 07/04/2013 12:50 PM, Volker Schmidt scrisse: PS: secondo me la foto per L2 nel wiki è sbagliata. Mostra una pista ciclabile separata dalla strada. Sono chiaramente visibili dei blocchi in cemento che rendono difficile l'attraversamento. Io avrei taggato questa sitazione come T2 Secondo me i blocchi non sono in cemento e mi pare anche abbastanza semplice passare dalla ciclabile alla strada. Cioe' la separazione fisica non e' abbastanza marcata da far pensare al caso T2. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Si ma il wiki non è che sia così chiaro, con tre o più modi di taggare , (o questa o questa). Si spera ci si accordi su una convenzione unica e che la OCM risponda adeguatamente con un miglior rendering. Il 04/07/2013 12:36, emmexx ha scritto: La maniera corretta di taggare e' quella indicata sul wiki. Il fatto che OCM abbia deciso di non gestire in maniera appropriata questi tag puo' dipendere da tanti motivi (pochi casi, rendering poco chiaro, mancanza di motivazione del gestore di OCM) ma il tagging non va fatto solo in funzione del rendering. I tag vengono usati anche per fare routing o per mappe diverse da OCM. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Domanda su accessi ciclabili nel forum
On 2013-07-04 at 12:51:17 +0200, Fabri wrote: Per il divieto di accesso non ho approfondito il CdS, ma ad esempio questo: http://www.flickr.com/photos/76225195@N07/9208259618/ vieta l'accesso a chiunque o solo ai motoveicoli esclusi i mezzi di soccorso? la strada è pedonale... se non c'è scritto niente sull'altro cartello vieta l'accesso ai *veicoli* [1]_, quindi non solo ai motoveicoli, ma a qualunque macchina che circola su strada guidata dall'uomo [2]_ [3]_, e quindi incluse biciclette, carriole, slitte [4]_ e quant'altro. Per il divieto di transito agli *autoveicoli* c'è un cartello diverso, con il disegno dell'auto all'interno. .. [1] 1. I segnali di divieto relativi alla circolazione di tutti i i veicoli sono: a) il segnale DIVIETO DI TRANSITO http://www.aci.it/i-servizi/normative/codice-della-strada/titolo-ii-della-costruzione-e-tutela-delle-strade/art-39-segnali-verticali/regolamento-art-39.html .. [2] http://www.aci.it/i-servizi/normative/codice-della-strada/titolo-iii-dei-veicoli/art-46-nozione-di-veicolo.html .. [3] http://www.aci.it/i-servizi/normative/codice-della-strada/titolo-iii-dei-veicoli/art-47-classificazione-dei-veicoli.html .. [4] ok, questa l'ho aggiunta per assurdo, ma è prevista http://www.aci.it/i-servizi/normative/codice-della-strada/titolo-iii-dei-veicoli/art-51-slitte.html -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
ma se metto già cicleway:right(o left)=lane perchè debbo metterci anche cycleway=lane, non mi sembra sia specificato. anche perchè da josm usando le preimpostazioni mette solo il primo tag e non anche cicleway=lane -- View this message in context: http://gis.19327.n5.nabble.com/Indicazioni-ciclabili-e-OCM-tp5767509p5768265.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Il 07/04/2013 01:09 PM, Volker Schmidt scrisse: Guardando meglio, penso addiritura che le foto per L1b e T2 sono state intercambiate. Ciao Volker, guarda meglio! :-) Nella foto di T2 c'e' un albero che separa la ciclabile dalla strada. La strada e' quella coi sampietrini, poi' c'e' lo spazio in cui si trova anche l'albero ed infine c'e' la ciclabile. Alcune delle foto scelte comunque non sono propriamente utili nel caso si abbiano dei dubbi. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Domanda su accessi ciclabili nel forum
On 2013-07-04 at 12:54:32 +0200, Martin Koppenhoefer wrote: 2013/7/4 Fabri erfab...@gmail.com Per il divieto di accesso non ho approfondito il CdS, ma ad esempio questo: http://www.flickr.com/photos/76225195@N07/9208259618/ vieta l'accesso a chiunque o solo ai motoveicoli esclusi i mezzi di soccorso? il segno vieta l'accesso a tutti i veicoli (ma solo veicoli), i mezzi di soccorso quando hanno esigenza possono fare qualsiasi cosa ragionevole (credo), quindi è un po' superfluo quel cartello. credo che in questo caso possano entrare anche i mezzi di soccorso non in emergenza, ma non ne sono sicura. ad esempio un ambulanza che entra a prendere persona con malore non grave, che avrebbero anche potuto accompagnare a braccia/barella fino all'inizio della via. -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Ok, allora sarebbe da correggere il wiki -- View this message in context: http://gis.19327.n5.nabble.com/landuse-tp5766839p5768269.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Indicazioni ciclabili e OCM
Il 07/04/2013 01:15 PM, Fabri scrisse: Si ma il wiki non è che sia così chiaro, con tre o più modi di taggare , (o questa o questa). Si spera ci si accordi su una convenzione unica e che la OCM risponda adeguatamente con un miglior rendering. A volte ci sono piu' modi di taggare perche' ci sono differenti visioni del mondo, altre perche' e' invalso l'uso di fare in un modo ma poi e' stato fatto ordine. La convenzione unica e' quella indicata nel wiki. Mi pare che includa praticamente tutti i casi che si trovano nella realta'. In caso di dubbio nulla vieta di creare una way con tag highway=cycleway. Per quanto riguarda il rendering, il problema evidenziato dall'OP lo avevo sollevato io ad aprile 2011 e mi pare avessi chiesto ad OCM se si poteva sistemare il rendering. Ma in realta' anche tra i mappatori italiano che avevano partecipato alla discussione non c'era una visione comune sul modo migliore per inserire i tag e visualizzarli. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Il giorno 04 luglio 2013 13:42, bredy bredy...@yahoo.it ha scritto: Ok, allora sarebbe da correggere il wiki In effetti sì. Mi segnali dove hai letto questa cosa, che verifichiamo se ci sono errori? Grazie, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
http://wiki.openstreetmap.org/wiki/Key:area http://wiki.openstreetmap.org/wiki/Key:area Sopra Higways area dice che un'area delimitata da una strada terziari che definisce anche una landuse grass -- View this message in context: http://gis.19327.n5.nabble.com/landuse-tp5766839p5768276.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Volete che ne approfittiamo per aggiungere la traduzione ita? Non c'è molto da tradurre, dovrebbe essere una cosa veloce :) Leonardo Il 04/07/2013 14:13, bredy ha scritto: http://wiki.openstreetmap.org/wiki/Key:area http://wiki.openstreetmap.org/wiki/Key:area Sopra Higways area dice che un'area delimitata da una strada terziari che definisce anche una landuse grass -- View this message in context: http://gis.19327.n5.nabble.com/landuse-tp5766839p5768276.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
2013/7/4 bredy bredy...@yahoo.it http://wiki.openstreetmap.org/wiki/Key:area http://wiki.openstreetmap.org/wiki/Key:area Sopra Higways area dice che un'area delimitata da una strada terziari che definisce anche una landuse grass Grazie, ho aggiunto un commento nella discussione per sentire il parere degli altri mappatori. Personalmente, eliminerei quella riga all'istante. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
2013/7/4 bredy bredy...@yahoo.it http://wiki.openstreetmap.org/wiki/Key:area http://wiki.openstreetmap.org/wiki/Key:area Sopra Higways area dice che un'area delimitata da una strada terziari che definisce anche una landuse grass allora, non è impossibile farlo così, e si fa anche per essere più veloce, ma è meno preciso, meno stabile, più pesante sul db e meno bello, quindi una serie di svantaggi contro questo stile di mappatura. Per me è sconsigliato di usare il centro della strada per delimitare aree adiacenti. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappa per Garmin del Piemonte da dati CTRN e OSM
2013/7/4 Kay F. Jahnke: Yet again, please forgive me for posting in english; English is welcome in talk-it as stated in http://wiki.openstreetmap.org/wiki/Mailing_lists if anyone feels like translating this posting, please do so, and thanks in advance! here is my translation: Ciao gruppo! Ho pubblicato il pacchetto di sviluppo per la mappa CTRN-OSM-GPS. Questo pacchetto contiene tutti gli script e gli stili che ho scritto, più alcune cose interessanti come i file di stile QGIS per la CTRN e le icone per la mappa. Il pacchetto può essere esaminato e scaricato da questo repository mercurial su bitbucket: https://bitbucket.org/kfj/ctrn-osm-gps-dev Il mio metodo per convertire degli shapefile ESRI con ogr2osm in una rappresentazione intermedia in formato OSM e poi direttamente in una mappa garmin con mkgmap può interessare altri map-maker là fuori, quindi anche se non siete piemontesi potreste trovare il pacchetto interessante. Ho impiegato parecchio tempo per ideare questa tecnica e può essere usata per qualsiasi shapefile ESRI (e altre fonti dati compatibili con OGR), usa solo strumenti liberi ed è completamente gestita tramite script. L'uso di strumenti liberi era particolarmente importante per me, questo settore ha molto software che non è libero, o che ha dei vincoli, o la cui versione gratuita ha delle limitazioni... sono sicuro che sapete di cosa sto parlando. E per automatizzare tutto il procedimento di conversione, gli strumenti grafici non sono la scelta migliore, quindi fare tutto con degli script è una bella soluzione :) Sono stato precedentemente criticato per la licenza che ho usato per la mappa CTRN-OSM-GPS (è CC-BY-NC-SA), anche se penso che sia una licenza appropriata e adatta per il mio lavoro combinato da diverse fonti - qui http://lists.openstreetmap.org/pipermail/talk-it/2012-November/031707.html Spero che questa pubblicazione mostri che non intendo impedire ad altri di emulare il mio lavoro e che voglio promuovere l'uso dei dati liberi. Kay (traduzione di Daniele Forsi) ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Il 04/07/2013 11:55, Simone Saviolo ha scritto: Il giorno 04 luglio 2013 11:48, bredy bredy...@yahoo.it mailto:bredy...@yahoo.it ha scritto: Interessante il link. Fa un esempio che potrebbe esser utile, per definire le aree landuse usa le linee delle strade, invece di crearsi delle aree a doc, certo che così bisogna spezzare le way in una marea di pezzetti e creare delle relazioni. Che ne dite? Dico NO, in maiuscolo, grassetto e corpo 72 :-) Riusare le way delle strade per i landuse è una cattiva idea per svariati motivi. Ricorderò solo la difficoltà nell'editing successivo e l'errore formale derivante dal fatto che le strade hanno una larghezza che non viene rappresentata dalla sola way. Disegna i landuse dove si trovano. È più corretto, bello e facile da mantenere. :-) :-) :-) _very good. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] tmc in italia - cciss
Il 04/07/2013 10:49, Simone Cortesi ha scritto: mappe non ne ho trovate, posso darti un link generico a wikipedia: http://en.wikipedia.org/wiki/Traffic_message_channel -- -S Ho trovato la versione italiana. :) http://it.wikipedia.org/wiki/Traffic_Message_Channel Ovviamente meno prolissa di quella inglese... -- Simone Girardelli ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Stazioni Meteo
Sto inserendo in OSM stazioni meteo amatoriali e non Questo permetterà per esempio in futuro di usare osm per creare una mappa su cui visualizzare le varie stazioni meteo con i loro dati In oltre sto a contattare (facendo ricerche su internet di stazioni meteo e forum specializzati) i gestori delle stazioni meteo per farmi dare le loro posizioni precise e incoraggiandoli a inserire da soli la loro stazione meteo Questo implica maggior pubblicità al progetto e possibili nuovi utenti Incoraggio utenti OSM a fare lo stesso magari in altri campi per esempio ho visto che c'è chi ha dei sismografi amatoriali e pubblica i dati online Saluti -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Offerte luglio in hotel 3 stelle Riccione per le vacanze in formula all inclusive pensione completa e spiaggia. Convenzioni con i parchi divertimento della romagna. Per info 0541607636 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12911d=4-7 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] landuse
Il 04/07/2013 13:42, bredy ha scritto: Ok, allora sarebbe da correggere il wiki Il wiki è fatto apposta per essere modificato e migliorato. Personalmente ti consiglio, prima di mappare di fare un giretto nei posti dove gli utenti mappano da diverso tempo. Tipo: http://www.openstreetmap.org/?lat=45.2791lon=8.4827zoom=14 http://www.openstreetmap.org/?lat=40.1365lon=8.5275zoom=14 http://www.openstreetmap.org/?lat=44.402662lon=8.677186zoom=19 http://www.openstreetmap.org/?lat=45.99131lon=13.46099zoom=16 Ciao Mario. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Stazioni Meteo
Il giorno 04 luglio 2013 19:43, Salemme Guido salemme.gu...@email.it ha scritto: Sto inserendo in OSM stazioni meteo amatoriali e non Bravo! Tempo fa avevo ripristinato (ed inserito altre ex novo) delle stazioni di monitoraggio della qualità dell'aria (http://overpass-turbo.eu/s/sL) usando questo sistema che probabilmente è quello che userai http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmonitoring_station Questo permetterà per esempio in futuro di usare osm per creare una mappa su cui visualizzare le varie stazioni meteo con i loro dati In oltre sto a contattare (facendo ricerche su internet di stazioni meteo e forum specializzati) i gestori delle stazioni meteo per farmi dare le loro posizioni precise e incoraggiandoli a inserire da soli la loro stazione meteo Questo implica maggior pubblicità al progetto e possibili nuovi utenti Incoraggio utenti OSM a fare lo stesso magari in altri campi per esempio ho visto che c'è chi ha dei sismografi amatoriali e pubblica i dati online Ti segnalo anche il progetto OpenWeatherMap, magari già che mettono i dati online possono caricarli anche qui http://openweathermap.org/ (c'è un plugin di Leaflet per fare le mappe con la situazione meteorologica :-) ) Saluti Ciao, Stefano -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Offerte luglio in hotel 3 stelle Riccione per le vacanze in formula all inclusive pensione completa e spiaggia. Convenzioni con i parchi divertimento della romagna. Per info 0541607636 Clicca qui: http://adv.email.it/cgi-bin/**foclick.cgi?mid=12911d=4-7http://adv.email.it/cgi-bin/foclick.cgi?mid=12911d=4-7 __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Open data pavia e wiki
Il 04 luglio 2013 10:39, Simone Cortesi ha scritto: 2013/7/4 Daniele Forsi dfo...@gmail.com: molto bene, l'ho assimilato per il confronto degli stradari http://www.forsi.it/osm/spellcheck/highway/stradario/Pavia/ 260 nomi sono solo in OSM, 470 solo nei dati del Comune e 299 sono in entrambi grazie. ogni quanto aggiorni? finora ho aggiornato manualmente una volta alla settimana con i dati del giovedì notte, ma non sempre sono stato regolare -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
