Re: [OSM-talk-fr] Mesure d'une distance à vol d'oiseau
En géographie, normalement on calcule la distance à vol d'oiseau sur l'ellipsoïde. L'ellipsoïde utilisée est celle utilisée par le système WGS84. La distance est alors la longueur de la ligne géodésique. Ce site [1] (en anglais) fait ce calcul. Il trouve bien le chemin par un pôle quand les deux points sont diamétralement opposés sur l'équateur. Le site propose également le calcul de points intermédiaires sur la géodésique. Ce site [2] dessine des grands cercles sur une carte pour un globe sphérique. Le site [1] a un lien (que je n'ai pas essayé) vers une page qui dessine des géodésiques sur un carte. [1] https://geographiclib.sourceforge.io/scripts/geod-calc.html [2] https://www.greatcirclemapper.net/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?
Des relations intermédiaires pour les tronçons, c'est proposé depuis longtemps par Jo (Polyglot). [1][2][3][4][5][6] Je suis d'accord avec Jo que ça serait une bonne idée. Surtout, ça simplifierait l'édition de la voirie et réduirait les problèmes de casse de relations. Et le maintien des relations d'itinéraire serait souvent moins de travail. Un exemple des problèmes du système actuel - J'ai introduit des ponts dans la ligne du chemin de fer à l'ouest d'Agde (34) [7] et ça a entraîné la modification de 13 relations d'itinéraire. La plupart des relations comptaient plus de mille membres. J'ai fait les itinéraires de bus d'Agde de cette façon. Ça marchait très bien avec le rendu Transport d'Andy Allan. Mais ça provoquait des erreurs signalées par Osmose. L'utilisateur chamdam est venu tout refaire «comme il faut» (et sans me contacter). Vous voudrez peut-être voir comment je l'ai fait. Alors, faites cette requête du serveur Overpass allemand pour l'état de la base en 2022. Je la donne pour l'outil curl à la ligne de commande mais vous pouvez la modifier pour d'autres outils. curl -H "Accept-Encoding: gzip" -g -o Agde_2022.osm.gz 'https://overpass-api.de/api/interpreter?data=[date:"2022-10-26T00:00:00Z;];(node(43.27,3.44,43.32,3.53);%20<;node(w);rel(id:2720050,2810674,3854048,14732422););out%20meta;' (C'est la seule façon que j'ai trouvé d'obtenir les relations route_master. Toutes les autres choses que j'ai essayé donnent un timeout.) À noter que JOSM ouvre les fichiers .osm.gz tel quel. Aussi, les arrêts ne sont pas dans les relations tronçon, ils restent dans les relations du parcours entier. Chaque chemin est membre d'un maximum de deux relations d'itinéraire de bus. [1] https://lists.openstreetmap.org/pipermail/talk-transit/2012-July/001626.html [2] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/069587.html [3] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/069776.html [4] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/070281.html [5] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/070286.html [6] https://lists.openstreetmap.org/pipermail/talk-fr/2014-July/070302.html [7] https://www.openstreetmap.org/changeset/67851999 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Problème Centipede
Le problème est résolu grâce à Stéphane Péneau. J'avais mis centipede.fr au lieu de caster.centipede.fr pour l'adresse du caster. Drôle d'effet quand même, qu'avec la mauvaise adresse on obtient les bases Trimble (30) et pas les bases ublox F9P (400+). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Problème Centipede
J'ai trouvé un problème avec le serveur Centipede. J'ai essayé quatre bases. Deux - AGDE et SETE - avec récepteur Trimble, marchent. Deux - ASAGI et CETTE - avec récepteur ublox F9P, ne marchent pas. Toutes sont marquées actives sur la carte Centipede. Mais les deux qui ne marchent pas sont absentes de la liste du caster (caster table). J'ai essayé de saisir ASAGI et CETTE avec deux clients différents. Avec Bluetooth GNSS (Android) le flux démarre et s'arrête toutes les quelques secondes et on obtient peu de paquets. Avec RTKLIB STRSVR il y a une erreur no mountp. Comment puis-je signaler ce problème? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-au] Can anyone make sense of this?
Looking at the example - this is a really complex situation where the roundabout is at the entrance to a multi-level car park with a fly-ramp taking off to an upper parking level. Is the roundabout on public land or is it part of the precinct for the associated shopping mall? I would imagine the "no U-turn" restriction applies to accessing the fly-ramp dangerously. So commenting generally based on this one situation is a bit risky. Adrian Get BlueMail for Android On 30 Jul 2021, 12:33, at 12:33, Andrew Harvey wrote: >Some of them like https://www.openstreetmap.org/relation/13031072 where >the >no-u-turn restriction is on the same way don't make sense, and it's >fair to >ask for further information about why it was added, and if that's not >provided then I think it's fine to remove. > >I admit that while I'd much prefer routers to fix their problems I've >been >given so much bad routing due to u-turns at intersections that I've >been >mapping some. I think microsoft mapped a lot, so it's common in the >database. I think at this point we might as well make an exception and >allow these traffic light no-u-turns to be mapped. > >In the roundabout case, that's why I dislike splitting the way into two >oneway. It would be better to have a single way and just tag it as a >traffic island or hard/soft median on that section or something. >Nonetheless some mappers do it this way and in that case, the no-u-turn >restriction is probably required. > >On Fri, 30 Jul 2021 at 09:46, Little Maps wrote: > >> If the edits are accurate, legally acquired, ethical and respectfully >> build upon the work of previous mappers then, imo, so be it. >“Necessary” vs >> “unnecessary” has never been a criteria for inclusion in OSM. If it >were, >> heaps of edits would be up for challenge. You’ve informed the editor >that >> the edits are not necessary and, assuming they’ve read your comment, >they >> are clearly happy to continue adding them. So be it. We all have >different >> interests and pre-occupations. That’s what makes OSM so unique and >> interesting, even if it is frustrating at times. It’s a big map. >> ___ >> Talk-au mailing list >> Talk-au@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-au >> > > > > >___ >Talk-au mailing list >Talk-au@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-GB] OSM UK's first tile layer
I have submitted a ticket to the JOSM developers. The ticket contains a fully worked-out patch to upgrade the EPSG:27700 projection from the Helmert transformation to the look-up table transformation. I'm afraid this is another somewhat long and technical message. But it does contain an explanation of why the Land Registry wms is actually sort-of correct. With my modified version of JOSM, .mif files are now transformed using the look-up table. This is with the hack I described before, where no projection is defined in the file, and you choose EPSG:27700 when the opendata plugin asks you. But .shp files which declare British National Grid are still transformed with the Helmert transformation. This must be down to the opendata plugin, because JOSM itself, as modified, does not know about the Helmert transformation any more. (I have put in a ticket for that, too, but without a patch.) I now understand better, the information in the EPSG registry. If you go to the page for projection 27700, and open the panel for the OSGB36 datum, it is not entirely clear, as I described before. But if you look at the page for the OSGB36 datum (transformation 7953), it spells out that this transformation uses the OSTN15 look-up table. However, transformation 7953 isn't referenced anywhere in the page for projection 27700. The more I look at this projection stuff, the worse it gets. The Land Registry only covers England and Wales. The Scottish counterpart is Registers of Scotland. I've also had a look at their opendata. The URL is a bit hard to find so I give it here https://ros.locationcentre.co.uk/inspire/ They too have a wms, which is here http://ros.datafeed.locationcentre.co.uk/geoserver/wms They offer .shp files in British National Grid and ETRS. I've already mentioned the issues raised by .shp files. Rob was hoping to compare the BNG and ETRS files, but that's not possible because Registers of Scotland have made a mistake in preparing the ETRS files. The BNG and ETRS files are identical. In other words, the ETRS file contains BNG coordinates in metres. I am a bit surprised that I might be the first to spot this and report it. (With shapefiles, the projection is defined in an accompanying .prj file. The .prj file uses a version of 'well-known text' which does not contain EPSG numbers. This will be part of the explanation for the issue with the opendata plugin. If the .prj file is missing, the only option with the opendata plugin is EPSG:4326 (WGS84), so removing the .prj file does not provide a workaround.) The Registers of Scotland wms is misaligned, just like the Land Registry one. Rob's examples align with the two wms. *But* I always launch JOSM from the command line. And I spotted an info message on the command line saying 'reprojecting from EPSG:27700'. So, a further discovery. Some background - We are familiar with online maps from various sources. Most of them use tms protocol with Web Mercator projection (EPSG:3857). Wms is different. The server offers the client a list of projections which it can deliver, and the client chooses which one to have. Suppose JOSM is set to EPSG:3857. The Land Registry wms does not offer EPSG:3857 so JOSM chooses the first projection which it understands, from the server's list - EPSG:27700. Then JOSM reprojects it, so the wms is misaligned because *JOSM* is using Helmert. And the Land Registry was right all along! The Registers of Scotland wms does offer EPSG:3857, so that is what JOSM chooses. And the wms is misaligned because the *wms server* is using Helmert. The wms also offers EPSG:27700. So if you set JOSM to EPSG:27700; and delete and re-add the wms layer so it is redownloaded in EPSG:27700; then the wms is misaligned because *JOSM* is using Helmert. [I mean delete the layer, not delete the entry in the imagery list.] With my modified version of JOSM, both wms are correctly aligned (provided, in the case of Registers of Scotland, that you set JOSM to EPSG:27700 before adding the wms layer). The alignment of Rob's examples does not change with my modified version of JOSM, so Rob's examples no longer align with the two wms. I should add that the other projections offered by the two wms servers, in as far as I have been able to test them, are all misaligned. In other words, both servers are using Helmert. I tested with JOSM and QGIS. I've had another look at proj6 and proj7 and they do in fact use the look-up table for EPSG:27700. One piece I found online suggests they fall back to the Helmert transformation if the look-up table file is not available. This explains how come QGIS is using the look-up table transformation for EPSG:27700. I've looked further into the issue of simplification of polygons (dropping of nodes). GDAL and ogr2ogr behave the same as QGIS. ogr2ogr has a simplify option but that only increases the amount of simplification: it won't reduce it below the preset minimum. QGIS uses GDAL, so it
Re: [Talk-GB] OSM UK's first tile layer
The test will be, if Rob is able to produce example areas processed with the OS look-up table transformation, do the misalignments go away? Sorry for a rather long and technical message. I've done some more investigation and testing. QGIS reckons EPSG:27700 is the OS look-up table transformation, while JOSM thinks it is the Helmert transformation. The ultimate authority is the EPSG registry https://epsg.org/crs_27700/OSGB-1936-British-National-Grid.html . Unfortunately that page is not entirely clear. But there is a reference to the OSTN15 grid file in a footnote, so I think EPSG:27700 is intended to be the look-up table transformation. So, apologies for saying previously that EPSG:27700 is the Helmert transformation. The work to incorporate a large number of projections into JOSM was done nearly five years ago. It is based on proj4. Both proj4 and proj5 have EPSG:27700 as the Helmert transformation (based on looking at the strings, and on the behaviour of JOSM). proj6 and proj7 have EPSG:27700 as the most basic transformation, which gives misalignments of over 100m (based on looking at the strings). By 'string', I mean the line of text that begins +proj=. Some file formats for geographic information (GIS files), can accommodate a range of projections. Most of these declare the projection near the beginning of the file. The Land Registry open data are such files and they declare EPSG:27700. If you process them with proj, or an app that uses proj, you are not going to get the right results unless you can override the declaration. The strange thing is that QGIS also uses proj. The developers of QGIS must have altered the definition of EPSG:27700 from the one built-in to proj. But I haven't discovered exactly what has been done. I set about loading some of the Land Registry open data into JOSM, with the look-up table transformation. With the opendata plugin, JOSM can read a range of GIS file formats. Unfortunately that does not include .gml, the format of the Land Registry files. The Land Registry suggest using QGIS, so I did. JOSM and QGIS have four formats in common, KML, geoJSON, Esri shapefile .shp, and MapInfo file .mif. I am a complete newbie to QGIS, but it is a nightmare! The option to disable projection handling (No CRS) does not work properly. (This would give a means of overriding the declaration in the file.) With three of the four formats for the output file, KML, .shp and .mif, QGIS simplified the polygons, weeding out nearly half of the nodes. QGIS gave no warning of this, and I could not find an option to turn off this behaviour. (There is an option to turn off this behaviour for rendering. Perhaps it would have turned it off for output too. But why were geoJSON files unaffected?) When writing a .mif file in EPSG:27700 projection, QGIS wrote the most basic transformation as the projection, without giving a warning. QGIS did this because the .mif format has limitations on the projection definitions that it can handle. Perhaps the latest version of QGIS is a bit buggy and I should have used the LTS version. I tried doing the transformation in QGIS, then loaded the output file into JOSM. All four file formats worked, and gave the same results (apart from the loss of nodes with three of the formats). So if you're using QGIS, I'd recommend doing it this way and using geoJSON. It doesn't even need the opendata plugin. If you want to do just the file format conversion in QGIS, and do the transformation in JOSM, it's more tricky. The KML and geoJSON formats are ruled out because they must by definition contain WGS 84 lats and longs. So you are stuck with the loss of nodes. The .shp format gives up to 5m misalignment because QGIS declares EPSG:27700 in the file and the opendata plugin provides no means for overriding the EPSG:27700 and using the custom projection I described previously. The .mif format works (in terms of getting no misalignment) if you do a simple hack. Open the .mif file in a text editor and change the fourth line from CoordSys Earth Projection 8, 79, "m", -2, 49, 0.9996012717, 40, -10 to CoordSys Nonearth Units "m" Bounds (0.0, 0.0) (130.0, 130.0) ensuring that none of the spaces are omitted. This means that no projection is defined in the file and the opendata plugin will then ask you which projection you want to use. You simply choose the custom projection, provided that you have previously set it up. (You may need to scroll down to see the Okay button.) The transformation in JOSM gives essentially the same results as the transformation in QGIS. For the newbie, here's how to do the transformation in QGIS. Launch QGIS. Create a new project. Then Layer > Add Layer > Add Vector Layer and open the .gml file you have downloaded from the Land Registry open data. Accept the suggested CRS of EPSG:27700 and close the Data Source Manager dialog. Then Layer > Save As > choose Format GeoJSON, filename as
Re: [Talk-GB] OSM UK's first tile layer
I can confirm that the Land Registry wms parcels appear to have been converted with the Helmert 7-element transformation (no look-up table). This gives a misalignment of up to 5 metres. It's ironic that the Land Registry don't seem to know where their parcels are to better than 5m. Now we know what EPSG:27700 does. It does the above transformation. I agree with Rob that the misalignment of 5m is obvious if you look at Hugh Town (Scilly). Both if you compare with the OSM data and if you compare with the tracklogs that have been uploaded to OSM. So this transformation won't do. I think we need to go for the look-up table. I've done some testing with JOSM. The look-up table transformation is not in JOSM's list of (thousands) of projections. But this custom projection does it: +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=40 +y_0=-10 +ellps=airy +units=m +nadgrids=OSTN02_NTv2.gsb +bounds=-9,49,2,61 +no_defs I expect something very similar would work in Mapnik. When you set up this custom projection, JOSM downloads the grid file from the JOSM server, and puts it in the JOSM cache folder under a modified name. There is then a wait of several seconds while JOSM configures the custom projection. You can also get JOSM to do the latest, OSTN15 transformation. The only change needed, is to the grid file. This needs some simple hacking because it's not supported. You don't change the custom projection, but you alter the file in the cache folder. So, find the file, copy its name, and then delete it. Download the OSTN15 grid file from the OS website. As Gareth says, you need OSTN15_NTv2_OSGBtoETRS.gsb, (and not the other way round). Put the file in the cache folder and rename it to the name you just copied. You then need to quit and relaunch JOSM for this change to 'take'. The difference between OSTN02 and OSTN15 is a shift, mostly in longitude, and in a similar direction throughout GB, of 1-2cm. With the look-up table transformation, there will still be a misalignment of 0.75m relative to WGS84, but this is a lot better than 5m. If there is consensus, then the wiki needs to be updated to recommend the OSTN15 transformation. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] OSM UK's first tile layer
The Ordnance Survey provides a transformation between OSGB36 and ETRS. It is described on this page https://www.ordnancesurvey.co.uk/gps/transformation/ and on the pages linked from there. The transformation is definitive. In other words, OSGB36 is redefined as being what you get when you apply the transformation to sets of ETRS co-ordinates. This must mean that if you compare an OS 1:1250 National Grid plan, with an older version of the plan from the era of OSTN02, features may have shifted slightly. The transformation involves a mathematical transformation, and an adjustment based on a look-up table, to make the result match the errors in the old triangulation system. The OS provides applications to do the transformation, both ways, for a range of platforms. It also provides source code, the look-up table, and details of the mathematical transformation. JOSM handles projections using proj. If you want to know what JOSM does with EPSG:27700, you need to know how it is defined in proj. The source code of JOSM includes the OSTN02 look-up table (15MB), but it can't be in the jar (also 15MB), so I don't know how that works. Rob asked about position errors from the Helmert transformation without a look-up table. Here are some examples. Larger errors Place error, m St Kilda 4.9 Scilly 4.7 Lizard Point 4.1 Butt of Lewis 3.2 King's Lynn2.7 Mallaig2.6 Flamborough Head 2.4 Colchester 2.4 Plymouth 2.4 Nottingham 2.3 Anglesey 2.1 Northampton2.0 North Foreland 1.9 Isle of Man S 1.9 Carmarthen 1.9 Smaller errors St Catherine's Pt 1.4 Carlisle 0.8 Edinburgh 0.6 Aberdeen 1.8 Thurso 1.6 Orkney 1.0 Foula (Shetland) 1.2 The errors are particularly small near Bristol, Edinburgh and Fair Isle. They exceed 2m in South Devon, Cornwall, East Anglia, Nottinghamshire, Lincolnshire, the East Riding of Yorkshire, Pembrokeshire, Anglesey and Western Scotland. +1 for referencing GB to ETRS. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV
Il y a deux ans environ, je voulais couper des chemins (ways) de chemin de fer pour introduire des ponts. Ces chemins étaient membres de plus que dix relations d'itinéraire. Comme toi, j'ai vu qu'il y avait deux genres de relation. Il y avait les itinéraires d'infrastructure, comme la ligne de Combs-la-Ville à Saint-Louis. Et il y avait les itinéraires passagers, les voyages sans correspondance proposés par la SNCF, comme le TGV 752. J'ai remarqué que les itinéraires passagers reflétaient l'état d'il y a cinq ans ou plus. Les relations étaient un vrai désordre. Toutes étaient cassées à multiples endroits avec des types diverses d'erreur. Quelques-unes étaient très longues avec jusqu'à trois mille membres. Le format de toutes les relations est un hybride de v1 et v2 des transports en commun. Il y a une liste des gares, et une liste des chemins dans les deux sens (sauf voie unique), sans les rôles forward ou backward. Les listes des chemins comprennent des blocs alternés de chemins dans le sens aller et chemins dans le sens retour. Les relations d'infrastructure contiennent souvent toutes les voies des gares, y compris les voies de garage et d'évitement. Les relations passagers contiennent souvent toutes les voies par lesquelles les trains pourraient passer par les gares. Je pense que les relations ont été créées ainsi par des enthousiastes des chemins de fer. Mais je n'ai pas cherché qui, ou pourquoi, ou si c'est documenté quelque part. J'ai passé des heures à faire une réparation partielle des plus-que-dix relations, sans changer le format. Une réparation entière aurait fallu beaucoup trop longtemps. Ainsi j'ai pu introduire les ponts sans empirer le bordel. À mon avis, un tel cas a besoin d'une méthode différente de cartographier les itinéraires. Les relations d'itinéraire devraient avoir comme membres, d'autres relations: des tronçons d'itinéraire. Ça pourrait être fait avec ou sans des relations superroute. On arriverait à une grande simplification. Et alors, que faire? Mettre en bonne état et à jour seulement les relations qui passent par ton coin, est un très grand boulot. Et en idéal, il faudrait discuter avec ceux qui cartographient les chemins de fer, quel est le format préféré des relations. Les relations sont utilisées par https://www.openrailwaymap.org/ et https://magosm.magellium.com/portail/#/carte p.ex. Supprimer des relations serait dommage, vu le temps que plusieurs contributeurs ont passé à les créer. À mon avis, il faudrait améliorer ou mettre à jour; ou bien laisser tel quel. À noter qu'il y a toujours des liaisons directes Lyon - Barcelone. Mais pas Lyon - Bordeaux, ça va plus vite maintenant via Paris que via Montpellier! Un projet du mois, peut-être? Mais je me demande s'il y aurait assez de contributeurs intéressés. Et comment découvrir la gamme des itinéraires passagers, vu qu'il n'y a plus de fiches horaires TGV disponibles en ligne? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-GB] Finally a RTK / NTRIP Broadcaster in London
@ Grant Slater
Thank you for spotting this and making it known.
One thing you need to know when using an RTK base station, is what is the
reference (datum). Unfortunately there is no convention for how this
information is given, and it is often not given at all. The stations listed by
Grant are on the Eurasian tectonic plate so the reference will be either ETRS
or ITRS ("WGS 84"). WGS 84 is the datum used in OSM.
I have previously connected to several of the stations on the list: DARE, HERS,
HERT and SHOE. All of these are on ETRS although HERS has a small position
error. I tried connecting to LICC and it is on ITRS. (I estimate there is a
position error, relative to ITRS, around 12cm too far north, 8cm too far west
and 31cm too high.) I think a mistake has been made in configuring the LICC
station. Incidentally, LICC is at Imperial College in South Kensington. There
is a site information page at
http://epncb.oma.be/_networkdata/siteinfo4onestation.php?station=LICC00GBR If
you click on Data Provided you can see any warnings that have been logged. It
was the warning here about a position error that prompted me to check it out.
The website I just referred to evidently expects the reference to be ETRS.
The stations on Grant's list are of a type known as Continuously Operating
Reference Stations (CORS). Stations of that type would be expected to produce
results consistent to the millimetre. The ITRS position of LICC shifts by a
millimetre every two weeks, so I hope they have an automated system, or at
least a simple system, for updating the position it is broadcasting.
If you have a consumer SatNav you probably can't tell the difference between
ETRS and ITRS. But if you are using RTK you certainly can tell the difference.
In south-east England, at the time of writing, ITRS gives a position 52.0cm
further north and 53.5cm further east than ETRS. This gives a horizontal
distance of 74.6cm. The horizontal distance increases by 2.4cm per year. The
altitude difference is less than 0.2cm.
If you record a tracklog using RTK from seven of the eight stations in the
list, the tracklog will be in ETRS. You will need to convert it to ITRS for use
in OSM. If the tracklog covers a small area, you can just apply a fixed offset
to the latitudes and longitudes. Unfortunately I don't know of any tool which
makes this simple to do.
Someone in France has organised funding for an independent network of open RTK
base stations. (The availability of free RTK base stations was even worse in
France than in the UK.) See https://centipede.fr/ They have produced detailed
instructions for setting up a base station, including a shopping list, how to
assemble the equipment, preconfigured software, and how to obtain the position
of the base station to within a couple of centimetres. It also covers setting
up a receiver for RTK. They have set up a server to broadcast all the streams
and there are already several dozen stations in operation. They will soon be
prevented from setting up a VRS, only by the cost of the software for doing
that. The documentation is all at https://jancelin.github.io/docs-centipedeRTK/
It is in French, but for those who don't speak French, I expect a well-known
online service would produce an adequate translation. There is a subscription
RTK stream service covering many countries, which professionals use. They no
longer quote prices on their web site, but when they did, the entry-level
subscription for real-time access was around £4000 per year. IIRC, that gave
the subscriber access to a maximum of five simultaneous VRS streams and
included access to a two-way satellite link, for areas where there was no
mobile phone signal.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk-be] Telenav Mapping Project
Hello Joost, Most likely we will begin next week to edit on the map. We will keep you all up to date with our progress and any edits that we might do. Thank you for your support. p.s. It’s nice too hear you visited Cluj-Napoca. If it has been a long time ago, the city has developed quite fast. From: joost schouppe Sent: Thursday, April 23, 2020 1:10 PM To: Adrian Budugan Cc: OpenStreetMap Belgium Subject: Re: [OSM-talk-be] Telenav Mapping Project Hi Adrian, Looking forward to your help! Do post here or on our Riot when you start the real work. Error fixing is always helpful. Having looked at the Improve OSM tools, I don't see how it could help you much? OpenStreetCam is rather limited in Belgium (most of us contribute to Mapillary instead, but the day someone provides a server that feeds both projects, I'm sure we'll switch to that!). And for the Cygnus tool, you need government data. There is road geometry, but the differences are largely because the official data is lagging. I'm not aware of Brussels traffic sign data. Best, Joost p.s. I really enjoyed CLuj Napoca when I was there many years ago Op do 23 apr. 2020 om 11:46 schreef Adrian Budugan mailto:adrian.budu...@telenav.com>>: Hello Joost, Thank you for your reply and for the info provided. Considering that we will be working remotely, we are always checking the history of the edits before making any changes. We also decided to first rely on notes, as you suggested, and edit only where we are 100% sure. We will be fixing errors using the Keep Right tool and add one ways and turn restrictions using Improve OSM. We will keep in touch as much as it is needed and thank you again for your feedback. Kind Regards, Adrian From: joost schouppe mailto:joost.schou...@gmail.com>> Sent: Wednesday, April 22, 2020 9:14 PM To: OpenStreetMap Belgium mailto:talk-be@openstreetmap.org>> Cc: Adrian Budugan mailto:adrian.budu...@telenav.com>> Subject: Re: [OSM-talk-be] Telenav Mapping Project Hi Adrian, To add to that, there's an overview of all the channels at our local chapter's website: https://openstreetmap.be/en/contact.html<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fopenstreetmap.be%2fen%2fcontact.html=E,1,6kwsDd2Yju2zANx8QqyDeIpPgudJlWTFGSk2vDYWqv-tFHc3MdQSguWOma8B215cFAKxQyUfim9cGWnc0Ix45aiFaEOM-fMBhfvI62g7LcNGPFQbRF441CYB9JBh=1> We have decent Mapillary coverage, but are constantly looking to get more and better cameras for our volunteers (hint, hint). There is good and recent imagery (properly indexed both in the imagery layer index and the JOSM index). There are also good basemaps from the government, which you can use for mapping. As always, both imagery and basemaps can be outdated - sometimes OSM is ahead, sometimes it isn't. There's quite an active community, so be mindful of the last edit date on object (I should know, I recently messed up JanFi's work). What data will you be basing your edits on? I would think that Brussels is mapped pretty well, so it might be hard to improve remotely. It might be useful to start off with just Notes, so that we can review them locally. That might avoid any editing conflict. I think the most active mapper in Brussels is bxl-forever, might be useful to engage him directly. Joost Op wo 22 apr. 2020 om 20:01 schreef Pieter Vander Vennet mailto:pieterv...@posteo.net>>: Hello Adrian and Telenav-team. Welcome in Belgium, the more support, the merrier. First of all, there is quite an active community in Belgium - I'm one of them, as are several others. As already mentioned, the matrix-chat is an excellent way to reach out to us and have questions answered quite fast - please join us here: https://riot.im/app/#/room/#osmbe:matrix.org<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2friot.im%2fapp%2f%23%2froom%2f%2523osmbe%3amatrix.org=E,1,ZGkjBhrLWkoupaR9yIk86KcQhWoz7dIRHHQIhynjwPUyZM7AtLEHNTtG4XoOIe6vMoTPy5YVYARE5VaR51HpCmFo6U_hKpYs6455_jpr5fdoWEs,=1> Second, I was wondering where you are based - the best way to map is by using local knowledge and by running around to see what the situation is. Also, being here IRL will allow us to meetup or to get in touch with the OpenKnowledge Belgium - they do great work for Open Source and Open Data. However, I presume that you will mostly be doing remote work, based on official data and mapillary streetview. This too can be useful, but the situation of Brussels is quite volatile and might change a lot. Don't be afraid to to ask us (or a local) to check up on the situation. At last, a lot of cyclists are using OSM in Brussels - the company I work for even hosts a professional cycle route planner for the city. Please, be careful not to break it. Especially when adding 'oneway=yes', this might force the routeplanner to consider this oneway for cyclists as well. Please, if it is clear that cyclists are allowed to go both ways, add 'oneway:bicycle=no' or, even
Re: [OSM-talk-be] Telenav Mapping Project
Hello Midgard, Thank you for your reply. We have indeed encountered many false-positive results from keep right during our edits. But as you mentioned, it helps bringing up any potential errors that we can review and then correct only if needed. Kind regards, Adrian -Original Message- From: Midgard Sent: Saturday, April 25, 2020 3:24 PM To: OpenStreetMap Belgium Subject: Re: [OSM-talk-be] Telenav Mapping Project Quoting Adrian Budugan (2020-04-23 13:29:32) > Hi Marc, > > It's nice to hear from you. From our first analysis, Brussels looks quite > complete and correctly mapped. We are looking to first correct any errors > that might come up by running the Keep Right tool. > Where there will be any doubts, we will leave notes and/or ask the community > before making any edits. > > Kind regards, > Adrian Keep right "errors" are not always real errors. I see a lot of almost-junction reports in my neighbourhood, but they're all false positives. Of course it highlights a lot of valid problems too. What I mean to say is, please don't map for the validator. Kind regards, M!dgard ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Telenav Mapping Project
Hi Marc, It's nice to hear from you. From our first analysis, Brussels looks quite complete and correctly mapped. We are looking to first correct any errors that might come up by running the Keep Right tool. Where there will be any doubts, we will leave notes and/or ask the community before making any edits. Kind regards, Adrian -Original Message- From: Marc Gemis Sent: Thursday, April 23, 2020 7:34 AM To: OpenStreetMap Belgium Subject: Re: [OSM-talk-be] Telenav Mapping Project Hallo Adrian, thanks for reaching out before starting the project. Just like the others here, I wonder how bad the situation is in Brussels in your eyes. Do you have an overview of the wrong/missing data that you will try to fix? Do you have a list of sources that you will use to correct those problems? This information is missing in the TelenavMapping page you are linking to. Without this information, it's hard to tell whether your remote work will improve the situation or undo the hard work of the local mapping community. As for Flandres, we had a "street complete' project a few years ago that added all missing roads. Furthermore, before I had spent 2 years or so on adding all the turn:lanes on motorways, trunk and primary road, mainly in Flandres but also in Brussels and Wallonia. It might be worth to do an update on that. Of course, in the meantime, others have joined that project and have updated the data all over the country. regards m. On Wed, Apr 22, 2020 at 1:09 PM Adrian Budugan wrote: > > Hi all, > > I am Adrian and I am part of the Mapping Team at Telenav. Our team started an > editing project in Belgium to make OpenStreetMap more navigable and accurate > in guidance. > > We will start editing in Brussels at the end of April, next week. There are > more details here - > https://github.com/TelenavMapping/EU_mapping_projects/issues/4. > > We will focus on one ways, turn restrictions, road geometry and quality > assurance. > > We we'd love to hear your advice on any local mapping guidelines, besides the > general OSM mapping ones (http://wiki.openstreetmap.org/wiki/Main_Page, > http://wiki.openstreetmap.org/wiki/Map_Features). > > Also, we appreciate any hints regarding available local or government data > that we might be able to us or anything else that might come in handy. > > If there are any other OSM communication channels for Belgium, please let us > know. > > If you have any questions or comments, please let me/us know. > > We are looking forward to hearing from you. > > > > Thank you! > > > > > > ___ > Talk-be mailing list > Talk-be@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Telenav Mapping Project
Hello Pieter,
It is nice to meet you too and thank you for your reply. Our mapping team is
based in Cluj-Napoca, Romania.
We are fully aware that mapping based on local knowledge beats remote mapping
and we will do our best to leave only a positive impact with our edits.
Alongside aerial official data we will also use street imagery such as
OpenStreetCam and Mapillary.
We appreciate letting us know of the situation and providing important
information such as the bicycle routes, which are an indeed an aspect that we
will take into consideration while editing.
Furthermore, we decided to use mainly notes until we accommodate with the area
and only edit where we are very sure.
We will keep in touch with any questions that might arise.
Kind Regards,
Adrian
From: Pieter Vander Vennet
Sent: Wednesday, April 22, 2020 9:00 PM
To: OpenStreetMap Belgium ; Adrian Budugan
Subject: Re: [OSM-talk-be] Telenav Mapping Project
Hello Adrian and Telenav-team.
Welcome in Belgium, the more support, the merrier.
First of all, there is quite an active community in Belgium - I'm one of them,
as are several others. As already mentioned, the matrix-chat is an excellent
way to reach out to us and have questions answered quite fast - please join us
here:
https://riot.im/app/#/room/#osmbe:matrix.org<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2friot.im%2fapp%2f%23%2froom%2f%23osmbe%3amatrix.org=E,1,xaykZ4okY3zmkGtm8GGDsc6rUAIDnnC6xSBekACwndDCCWYPQRJa6hbiRxYjVbdX-DDP_ds94Jj6Ws8eHMlsTe6xeRuGfms8oGhzt8RicA,,=1>
Second, I was wondering where you are based - the best way to map is by using
local knowledge and by running around to see what the situation is. Also, being
here IRL will allow us to meetup or to get in touch with the OpenKnowledge
Belgium - they do great work for Open Source and Open Data.
However, I presume that you will mostly be doing remote work, based on official
data and mapillary streetview. This too can be useful, but the situation of
Brussels is quite volatile and might change a lot. Don't be afraid to to ask us
(or a local) to check up on the situation.
At last, a lot of cyclists are using OSM in Brussels - the company I work for
even hosts a professional cycle route planner for the city. Please, be careful
not to break it. Especially when adding 'oneway=yes', this might force the
routeplanner to consider this oneway for cyclists as well. Please, if it is
clear that cyclists are allowed to go both ways, add 'oneway:bicycle=no' or,
even better, add the appropriate cycleway tags ('cycleway=lane',
'cycleway=track', ...)
Kind regards,
Pietervdvn
On 22.04.20 13:08, Adrian Budugan wrote:
Hi all,
I am Adrian and I am part of the Mapping Team at Telenav. Our team started an
editing project in Belgium to make OpenStreetMap more navigable and accurate in
guidance.
We will start editing in Brussels at the end of April, next week. There are
more details here -
https://github.com/TelenavMapping/EU_mapping_projects/issues/4.
We will focus on one ways, turn restrictions, road geometry and quality
assurance.
We we'd love to hear your advice on any local mapping guidelines, besides the
general OSM mapping ones (http://wiki.openstreetmap.org/wiki/Main_Page,
http://wiki.openstreetmap.org/wiki/Map_Features).
Also, we appreciate any hints regarding available local or government data that
we might be able to us or anything else that might come in handy.
If there are any other OSM communication channels for Belgium, please let us
know.
If you have any questions or comments, please let me/us know.
We are looking forward to hearing from you.
Thank you!
___
Talk-be mailing list
Talk-be@openstreetmap.org<mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
--
Met vriendelijke groeten,
Pieter Vander Vennet
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Telenav Mapping Project
Hello Joost,
Thank you for your reply and for the info provided. Considering that we will be
working remotely, we are always checking the history of the edits before making
any changes. We also decided to first rely on notes, as you suggested, and edit
only where we are 100% sure.
We will be fixing errors using the Keep Right tool and add one ways and turn
restrictions using Improve OSM.
We will keep in touch as much as it is needed and thank you again for your
feedback.
Kind Regards,
Adrian
From: joost schouppe
Sent: Wednesday, April 22, 2020 9:14 PM
To: OpenStreetMap Belgium
Cc: Adrian Budugan
Subject: Re: [OSM-talk-be] Telenav Mapping Project
Hi Adrian,
To add to that, there's an overview of all the channels at our local chapter's
website:
https://openstreetmap.be/en/contact.html<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fopenstreetmap.be%2fen%2fcontact.html=E,1,6kwsDd2Yju2zANx8QqyDeIpPgudJlWTFGSk2vDYWqv-tFHc3MdQSguWOma8B215cFAKxQyUfim9cGWnc0Ix45aiFaEOM-fMBhfvI62g7LcNGPFQbRF441CYB9JBh=1>
We have decent Mapillary coverage, but are constantly looking to get more and
better cameras for our volunteers (hint, hint).
There is good and recent imagery (properly indexed both in the imagery layer
index and the JOSM index). There are also good basemaps from the government,
which you can use for mapping.
As always, both imagery and basemaps can be outdated - sometimes OSM is ahead,
sometimes it isn't. There's quite an active community, so be mindful of the
last edit date on object (I should know, I recently messed up JanFi's work).
What data will you be basing your edits on? I would think that Brussels is
mapped pretty well, so it might be hard to improve remotely.
It might be useful to start off with just Notes, so that we can review them
locally. That might avoid any editing conflict.
I think the most active mapper in Brussels is bxl-forever, might be useful to
engage him directly.
Joost
Op wo 22 apr. 2020 om 20:01 schreef Pieter Vander Vennet
mailto:pieterv...@posteo.net>>:
Hello Adrian and Telenav-team.
Welcome in Belgium, the more support, the merrier.
First of all, there is quite an active community in Belgium - I'm one of them,
as are several others. As already mentioned, the matrix-chat is an excellent
way to reach out to us and have questions answered quite fast - please join us
here:
https://riot.im/app/#/room/#osmbe:matrix.org<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2friot.im%2fapp%2f%23%2froom%2f%2523osmbe%3amatrix.org=E,1,ZGkjBhrLWkoupaR9yIk86KcQhWoz7dIRHHQIhynjwPUyZM7AtLEHNTtG4XoOIe6vMoTPy5YVYARE5VaR51HpCmFo6U_hKpYs6455_jpr5fdoWEs,=1>
Second, I was wondering where you are based - the best way to map is by using
local knowledge and by running around to see what the situation is. Also, being
here IRL will allow us to meetup or to get in touch with the OpenKnowledge
Belgium - they do great work for Open Source and Open Data.
However, I presume that you will mostly be doing remote work, based on official
data and mapillary streetview. This too can be useful, but the situation of
Brussels is quite volatile and might change a lot. Don't be afraid to to ask us
(or a local) to check up on the situation.
At last, a lot of cyclists are using OSM in Brussels - the company I work for
even hosts a professional cycle route planner for the city. Please, be careful
not to break it. Especially when adding 'oneway=yes', this might force the
routeplanner to consider this oneway for cyclists as well. Please, if it is
clear that cyclists are allowed to go both ways, add 'oneway:bicycle=no' or,
even better, add the appropriate cycleway tags ('cycleway=lane',
'cycleway=track', ...)
Kind regards,
Pietervdvn
On 22.04.20 13:08, Adrian Budugan wrote:
Hi all,
I am Adrian and I am part of the Mapping Team at Telenav. Our team started an
editing project in Belgium to make OpenStreetMap more navigable and accurate in
guidance.
We will start editing in Brussels at the end of April, next week. There are
more details here -
https://github.com/TelenavMapping/EU_mapping_projects/issues/4.
We will focus on one ways, turn restrictions, road geometry and quality
assurance.
We we'd love to hear your advice on any local mapping guidelines, besides the
general OSM mapping ones (http://wiki.openstreetmap.org/wiki/Main_Page,
http://wiki.openstreetmap.org/wiki/Map_Features).
Also, we appreciate any hints regarding available local or government data that
we might be able to us or anything else that might come in handy.
If there are any other OSM communication channels for Belgium, please let us
know.
If you have any questions or comments, please let me/us know.
We are looking forward to hearing from you.
Thank you!
___
Talk-be mailing list
Talk-be@openstreetmap.org<mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
--
Met vriendelijke
[OSM-talk-be] Telenav Mapping Project
Hi all, I am Adrian and I am part of the Mapping Team at Telenav. Our team started an editing project in Belgium to make OpenStreetMap more navigable and accurate in guidance. We will start editing in Brussels at the end of April, next week. There are more details here - https://github.com/TelenavMapping/EU_mapping_projects/issues/4. We will focus on one ways, turn restrictions, road geometry and quality assurance. We we'd love to hear your advice on any local mapping guidelines, besides the general OSM mapping ones (http://wiki.openstreetmap.org/wiki/Main_Page, http://wiki.openstreetmap.org/wiki/Map_Features). Also, we appreciate any hints regarding available local or government data that we might be able to us or anything else that might come in handy. If there are any other OSM communication channels for Belgium, please let us know. If you have any questions or comments, please let me/us know. We are looking forward to hearing from you. Thank you! ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] Voies OSM inconnues de FANTOIR
Je n'ai pas vu un libellé FANTOIR changer, jusqu'à l'année dernière. Et puis Janvier 2019 340030085U CHE DE L ANGE GARDIEN 340030748P CHE DES EMPETRES 340032011M CHE DES FLAMANTS ROSES 340032028F IMP DE LA SAGUE 340032306H RUE VIGNIER Novembre 2019 340030085U IMP DE L ANGE GARDIEN 340030748P IMP DES EMPETRES 340032011M IMP DES FLAMANTS ROSES 340032028F IMP DE LA SAGNE 340032306H RUE CLAUDE VIGNIE En chaque cas, la mairie a changé le nom de la voie par arrêté. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-au] parking and bike lane
I am an occasional editor who fixes the occasional mistake affecting cyclists. As a cyclist I am one of many cyclists equally baffled by bike lanes that start and end randomly. Maybe we are expected to teleport. One such type in my suburb is short sections (3metres) of lane marking with the bike logo about every 100m of road. Saving paint I guess. But how to mark it up? Cheers Adrian Get BlueMail for Android On 29 Dec 2019, 14:21, at 14:21, Graeme Fitzpatrick wrote: >Thanks > >Graeme > > >On Sat, 28 Dec 2019 at 16:52, David Wales >wrote: > >> I prefer to use separate ways for separate foot paths. >> > >As do I. > > >> On 28 December 2019 3:02:30 pm AEDT, Sebastian Spiess > >> wrote: >>> >>> >>> I do welcome comments. In particular regarding how to go about the >cycle >>> way and the roundabout. >>> >> >Looks OK to me, but I've also wondered how bike lanes are supposed to >work >through roundabouts, when there's nothing marked on the road? > > Thanks > >Graeme > > > > >___ >Talk-au mailing list >Talk-au@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-talk-fr] Retrouver facilement le changeset ayant supprimé un objet
+1 Après quelques recherches - j'ai fouillé le changeset ayant crée les bâtiments voisins... J'ai l'impression que le bâtiment du 11 Rue Louis Bonnet a été manqué lors de l'import du Cadastre, et qu'il n'a jamais été dans la BDD OSM. Pour le problème en général, il n'y a pas de moyen simple (sauf Potlatch 1 si ça marche toujours). L'installation allemande d'Overpass contient tout l'historique depuis le changement de la licence en 2012. Le meilleur qu'on peut faire, c'est comme Marc. Télécharger des extraits de l'état de la BDD à des dates choisies. Ouvrir les extraits avec JOSM et trouver l'objet avant qu'il fut supprimé. Maintenant vous avez l'id de l'objet. Télécharger l'historique de l'objet pour trouver le changeset ayant supprimé l'objet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-au] Copying address from business website?
Might be issues where contact address (e.g. head office) being copied is different to physical location on map. Adrian Hobbs Sent from BlueMail On 22 Jul. 2019, 15:21, at 15:21, Andrew Harvey wrote: >This has come up a few times on the mailing lists, and the advise >usually >given is it's okay to source a few facts here and there like the >address or >contact number, but just don't start taking a whole database of venues >and >copy that database. > >On Mon, 22 Jul 2019 at 13:06, Kim Oldfield >wrote: > >> Is it acceptable to copy a street address (and other contact details) >> from a business's webpage? >> >> For example in https://www.openstreetmap.org/changeset/72452124 (what >> changed is easier to see at >> https://osmlab.github.io/osm-deep-history/#/way/705884944 ) I added >the >> street address as listed on their website. >> >> If this isn't acceptable, what is an acceptable way of getting an >> address if it is not obvious during a site survey? >> >> Regards, >> Kim >> >> ___ >> Talk-au mailing list >> Talk-au@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-au >> > > > > >___ >Talk-au mailing list >Talk-au@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-Talk-ZA] Mapping traditional councils as boundary=aboriginal_lands
@Grant Slater you're on the DWG, right? And you have experience getting SA government people to release data. Do you have advice on how we should request and what form of release we need? I have a contact at DRDLR who sent me the shapefile. On Thu, 11 Jul 2019 at 20:51, Adrian Frith wrote: > > There are 800 in the shapefile that I have from DRLDR. I guess the > next step is to get permission from them and then talk to the Data > Working Group. > > On Sat, 6 Jul 2019 at 10:47, Reuben Honigwachs via Talk-ZA > wrote: > > > > Since nobody has chimed in, yet, let me say this is a wonderful idea and > > I'll gladly support the effort. > > > > Do you have a rough idea of how many there are? > > > > Best, Reuben > > > > On Mon, 1 Jul 2019 at 15:20, Adrian Frith wrote: > >> > >> Hi talk-za, > >> > >> Do you think it would be appropriate for us to map the traditional > >> councils (formerly "tribal authorities") with the tag > >> boundary=aboriginal_lands[1]? I have mapped one as an example > >> (Batlhaping ba ga Mothibi) which you can see on the map at [2]. > >> > >> If we were to go ahead I suppose we might have to get formal > >> permission from the Department of Rural Development and Land Reform > >> which seems to be the custodian of the boundary data (of which I have > >> a copy). > >> > >> Your thoughts? > >> Adrian > >> > >> [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands > >> [2] https://www.openstreetmap.org/#map=10/-27.8342/24.5359 ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
Re: [OSM-Talk-ZA] Mapping traditional councils as boundary=aboriginal_lands
There are 800 in the shapefile that I have from DRLDR. I guess the next step is to get permission from them and then talk to the Data Working Group. On Sat, 6 Jul 2019 at 10:47, Reuben Honigwachs via Talk-ZA wrote: > > Since nobody has chimed in, yet, let me say this is a wonderful idea and I'll > gladly support the effort. > > Do you have a rough idea of how many there are? > > Best, Reuben > > On Mon, 1 Jul 2019 at 15:20, Adrian Frith wrote: >> >> Hi talk-za, >> >> Do you think it would be appropriate for us to map the traditional >> councils (formerly "tribal authorities") with the tag >> boundary=aboriginal_lands[1]? I have mapped one as an example >> (Batlhaping ba ga Mothibi) which you can see on the map at [2]. >> >> If we were to go ahead I suppose we might have to get formal >> permission from the Department of Rural Development and Land Reform >> which seems to be the custodian of the boundary data (of which I have >> a copy). >> >> Your thoughts? >> Adrian >> >> [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands >> [2] https://www.openstreetmap.org/#map=10/-27.8342/24.5359 ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
[OSM-Talk-ZA] Mapping traditional councils as boundary=aboriginal_lands
Hi talk-za, Do you think it would be appropriate for us to map the traditional councils (formerly "tribal authorities") with the tag boundary=aboriginal_lands[1]? I have mapped one as an example (Batlhaping ba ga Mothibi) which you can see on the map at [2]. If we were to go ahead I suppose we might have to get formal permission from the Department of Rural Development and Land Reform which seems to be the custodian of the boundary data (of which I have a copy). Your thoughts? Adrian [1] https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands [2] https://www.openstreetmap.org/#map=10/-27.8342/24.5359 ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-za
Re: [talk-au] Wadbilliga Road south east NSW marked 4WD only
Are the two mutually exclusive? Road classification versus surface condition? First time I drove this road it was smooth as - just been graded. Last was after heavy rain and an army tank would have had trouble. Adrian Sent from BlueMail On 18 Jun. 2019, 16:08, at 16:08, Warin <61sundow...@gmail.com> wrote: >Hi, > >This appears to be an error. On the LPI Base map it looks like a >tertiary rd.. > >Way: Wadbilliga Road (380747553) ... this extends to the east as well. > > >Any objections to removing the 4WD only and upping it to tertiary >class? > > >___ >Talk-au mailing list >Talk-au@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Aufwertung der Region Hochfranken im Forschungsprojekt Mobilität Digital Hochfranken (MobiDig, gefördert durch BMVI)
Hallo Martin, es sind nicht nur Behördenmitarbeiter sondern auch Mitarbeiter von Unternehmen. Ich vermute einfach, dass der Datenschutz eine Veröffentlichung der personenbezogenen Daten ohne vorherige Einwilligung und ohne Bereitstellung einer Datenschutzerklärung mit Nennung eines Datenschutzbeauftragten (ich nehme an, Vereine mit mehr als 10 Mitgliedern brauchen das) nicht zulässt. Sollte es Probleme geben, ließe sich immer noch mit dem Unternehmen / der Behörde direkt Kontakt aufnehmen (Kontaktinformationen werden nicht geschwärzt weil das nicht unter den Datenschutz fällt) und das Original dort einsehen. Grundsätzlich wäre aber auch ohne zu wissen, wer direkt unterschrieben hat, klar, dass hier ein Einverständnis offiziell vorliegt, bei dem eine Prüfung nicht ausgeschlossen ist. Das ist für mich genau das wert, was es wert sein muss, oder nicht? Grüße! Adrian -Ursprüngliche Nachricht- Von: Martin Koppenhoefer Gesendet: Donnerstag, 13. September 2018 09:46 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Aufwertung der Region Hochfranken im Forschungsprojekt Mobilität Digital Hochfranken (MobiDig, gefördert durch BMVI) sent from a phone > On 13. Sep 2018, at 09:01, Joachim Kast wrote: > > Du kannst die Erklärungen mit geschwärzten Namen als PDF ins Wiki > stellen. Hauptsache es gibt für eventuelle Nachfragen ein Aktenzeichen > und allgemeine Kontaktadresse der Behörde. nicht, dass ich hier konkret an den Namen interessiert wäre, aber ist das jetzt wirklich so, dass Unterschriften, die Behördenmitarbeiter in Ausübung ihrer Funktion leisten, unter den Schutz der Personendaten fallen? Wenn jemand die Authentizität der Dokumente anzweifeln sollte, wieviel ist dann ein Dokument wert, wo Namen und Unterschriften geschwärzt sind? Gruß, Martin Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Aufwertung der Region Hochfranken im Forschungsprojekt Mobilität Digital Hochfranken (MobiDig, gefördert durch BMVI)
Sehr geehrte Damen und Herren, ich hatte es schon zweimal versucht, aber die E-Mail ging leider nicht durch an die Mailingliste, ich hatte nun eine Vermutung, woran es gelegen haben könnte und versuche es noch einmal! Wir führen derzeit ein Digitalisierungsprojekt im Mobilitätsbereich durch, Mobilität Digital Hochfranken, mehr Infos dazu unter: http://www.bmvi.de/SharedDocs/DE/Artikel/DG/mfund-projekte/mobilitaet-digita l-hochfranken-mobidig.html In diesem vom BMVI geförderten Projekt wollen wir auch auf Basis des OpenStreetMap Datensatzes der Region Hochfranken (besteht auf Stadt Hof, Landkreis Hof und Landkreis Wunsiedel im Fichtelgebirge, alle drei Gebietskörperschaften sind im Projektkonsortium) Daten analysieren und algorithmisch auswerten. Unser Ziel ist es, anonymisierte Bewegungsmuster vorherzusagen, um Verbesserungen in der Nahverkehrsversorgung zu erreichen. Dazu bedarf es auch einer möglichst aktuellen und fehlerfreien Datenbasis in OpenStreetMap von dieser Region. Wir möchten dazu mit wissenschaftlichen Hilfskräften Daten der drei Gebietskörperschaften in OpenStreetMap einstellen sowie vorhandene Daten korrigieren. Für die entsprechenden Daten liegen ausdrückliche Genehmigungen der drei Gebietskörperschaften vor. Konkret betrifft dies z. B. Haltestellen und Linien von Stadtbussen in Hof, sowie Daten zu Parkplätzen, POIs in der gesamten Region (wie Freizeit, Schulen, Einkaufsmöglichkeiten) und weiteren Daten dieser Art, die in OpenStreetMap ein Äquivalent haben. Studierende und Mitarbeiter im Projekt (mich eingeschlossen) würden gerne die gesamte Region Hochfranken Schritt für Schritt in Bezug auf diese für die Mobilität wichtigen Daten aufwerten. Wir haben den Vorteil, dass wir auf Grundlage von OpenStreetMap wertvolle Zeit für ungelöste Probleme in unserem Projekt gewinnen, wenn wir keine eigene Datenbasis aufbauen müssen. Die OSM Foundation hat den Vorteil, dass Sie Verbesserungen im Kartenmaterial unentgeltlich und unbegrenzt nichtexklusiv verwertbar nach der ODbL erhält. Wie stellen wir Ihnen die Einverständniserklärungen unserer Partner bzw. von uns so zur Verfügung, dass Sie nachhaltig und ohne Verletzung des Datenschutzes der Personen, welche die Erklärungen unterzeichnet haben, diese Belege verfügbar haben? Wir möchten sicherstellen, dass jegliche Haftungsansprüche gegenüber der OSM Foundation ausgeschlossen sind und Ihnen diese Tatsachen bekannt sind, sodass wir unsere für den OpenStreetMap Datensatz nutzbaren Datenbestände problemlos einpflegen bzw. die vorhandenen Daten danach prüfen und ggf. korrigieren können. Gibt es von Ihren Seiten aus noch Hinweise, die zu beachten sind, die nicht bereits in den einschlägigen Dokumentationen behandelt werden, oder die speziell erwähnenswert sind? Ich bedanke mich für Ihre Unterstützung und freue mich, dass wir die Datenbasis für die Region Hochfranken ein Stück aufwerten können! Mit freundlichen Grüßen, Best regards, Adrian Wöltche, M.Sc. Wissenschaftlicher Mitarbeiter / Research Assistant Multimediale Informationssysteme Institut für Informationssysteme der Hochschule Hof (iisys) Institute of Information Systems at Hof University Alfons-Goppel-Platz 1 95028 Hof / Saale Germany Phone +49 9281 409-6277 Fax +49 9281 409-55-6277 adrian.woelt...@iisys.de www.iisys.de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Import OSM -> GeoServer Luxembourg et la grande région
Avec cette requête à l'Overpass API [1] curl -H "Accept-Encoding: gzip" -g -o 49.33_5.73_50.18_6.68.osm.gz 'https://overpass-api.de/api/interpreter?data=(node(49.33,5.73,50.18,6.68);%20<;node(w););out;' j'ai obtenu un fichier de 80Mo (550Mo décompressé) en 2 minutes environ. Le fichier ne contient pas les relations parents des relations, donc tu n'auras pas les superroute et route_master p. ex. Mais tu n'en as peut-être pas besoin. Si la zone que tu souhaites dépasse les limites de l'Overpass API, je conseille ainsi. Télécharger http://download.geofabrik.de/europe/luxembourg-180708.osm.pbf http://download.geofabrik.de/europe/belgium-180708.osm.pbf http://download.geofabrik.de/europe/france/lorraine-180708.osm.pbf http://download.geofabrik.de/europe/germany/rheinland-pfalz-180708.osm.pbf http://download.geofabrik.de/europe/germany/saarland-180708.osm.pbf En choisissant des fichiers avec la même date dans le nom plutôt que -latest, tu assures que les fichiers ont tous été découpés du même fichier maître. Ceci, à son tour assure qu'on peut fusionner les fichiers sans trou, sans doublon, et sans conflit. (La date est un exemple.) Fusionner les fichiers et clipper selon un polygone avec osmconvert [2]. Osmconvert est beaucoup plus rapide qu'osmosis et beaucoup plus facile à installer qu'osmium [3]. J'ai fait ce que je conseille avec succès, avec les fichiers France et Grande-Bretagne, en utilisant osmconvert. [1] https://wiki.openstreetmap.org/wiki/Overpass_API [2] https://wiki.openstreetmap.org/wiki/Osmconvert [3] https://wiki.openstreetmap.org/wiki/Osmium Adrian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-au] Road name abbreviation exception?
Maybe I am missing something here, but to my mind road and place naming is pretty clear cut. See:- "Guidelines for the determination of place names" a fact sheet by the Geographic Names Board of NSW http://www.gnb.nsw.gov.au/__data/assets/pdf_file/0010/58843/Guidelines_determination_placenames_2017.pdf and "6.7 Principles of Road naming" page 97 of the NSW Addressing User Manual http://www.gnb.nsw.gov.au/__data/assets/pdf_file/0007/199411/2018_NSW_Addressing_User_Manual.pdf Although these relate to NSW, I imagine there are similar arrangements in all states and territories. If OSM uses anything different it will only cause difficulties. I guess that, as with all standards, there will be exceptions. But OSM should then go with whatever the legal name is. Cheers Adrian Hobbs tel: 0427 310 938 email: adrian.ho...@grapevine.com.au On 29/06/2018 9:08 PM, Richard Fairhurst wrote: Warin wrote: I expand these out to Saint. I think that is correct in the English language. It is expressly _incorrect_ in British English and if this were a UK discussion you would be asked to put them back to St. I can't speak for Australian English but it wouldn't surprise me if it were the same. https://help.openstreetmap.org/questions/19609/saint-or-st-is-there-an-official-osm-policy Richard -- Sent from: http://gis.19327.n8.nabble.com/Australia-f5416966.html ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-talk-fr] Géodésiques IGN dans Osmose
Il y a quelque temps, j'ai fait deux noeuds conformément au wiki. Ce n'est pas facile. https://www.openstreetmap.org/node/518577471 - Sète, Mt St-Clair https://www.openstreetmap.org/node/3104840629 - Agde, Mt St-Loup J'ai fait les noeuds à partir des fiches IGN telles qu'elles étaient, 3430109 point a et 3400305 point a. (Les bornes sont toutes les deux détruites mais elles donnent une bonne idée de l'altitude des sommets.) Les fiches donnent les altitudes par rapport au NGF-IGN 1969. L'IGN fournit une grille qu'il faut interpoler, RAF09, qui donne l'hauteur du zéro IGN69 au dessus de l'ellipsoïde IAG-GRS 1980. Donc il s'agit d'un ellipsoïde, GRS80, d'un géoïde, EGM96, et d'un système altimétrique, IGN69. J'ai fait ainsi (en mètres). Mt St-Clair Mt St-Loup Hauteur zéro IGN69 p.r. à GRS80 49.52 49.39[RAF09] Hauteur géoïde EGM96 p.r. à GRS80 50.20 50.12[1] Altitude IGN69 (depuis la fiche) 175.6 112.8 Altitude GRS80 (par RAF09) 225.12 162.19 Altitude EGM96 174.92 112.07 [1] https://geographiclib.sourceforge.io/cgi-bin/GeoidEval Dans la zone de ces noeuds, la différence entre l'altitude IGN69 et l'altitude EGM96 est environ 0,7m. À noter que les fiches IGN emploient toujours la grille vieille RAF98. La différence RAF09-RAF98 est 5cm dans la zone de ces noeuds. Il vaut mieux ne pas extraire les altitudes GRS80 des fiches - l'altitude IGN69 est le chiffre de base et l'altitude GRS80 est un chiffre dérivé. Hauteur zéro IGN69 p.r. à GRS80 49.47 49.34[RAF98] ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-ie] What to do about sloppy mapping errors
I've recently retired and moved to live in West Cork. As an experienced hill walker I have been using GAIA GPS to explore new routes across the hills and mountains in the west of Ireland. GAIA GPS uses OSM and I noticed that some local features such as buildings were missing from OSM so I enroled as a contributor a few months back. I spent a happy evening adding local features which I know exist using the aerial photo backdrop for accuracy. I was quite disheartened next day when less than half of my new additions appeared on the map so I haven't been back. However, I have recently noticed quite a number of significant errors on OSM in my locality and I'd really like to EITHER go in and correct someone else's carelessness OR simply report the error(s) and let someone else put them right. I think I could contribute quite a lot to OSM in West Cork and Kerry simply by checking out stuff which I suspect to be wrong. For instance north of Bantry is a well known col shown as "Priest's Leap 572m" despite the fact that a) it isn't that high, b) it's shown below the 450m contour and c) even the nearby hill top is only 520m. This isn't even a typo because it isn't 472m either! Some of my other "errors" relate to features shown as roads which are actually overgrown tracks which you couldn't even walk along much less drive and certainly NOT a public road. In one case there is a "track" across a field on OSM which was shown on the aerial photos as no more than the marks left by a tractor on one pass. Definitely neither a road nor a track. Am I authorised to start cleaning up these blunders or should I just go back to using OS maps? cheers, Adrian. ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-GB] Monitoring OSM changes (was Re: natural=heath)
On 09/01/17 14:44, Ed Loach wrote: Adrian wrote: I did set up some changes-in-a-given-area RSS feeds from ITOworld years ago (I'd explain what they are better, but while the feeds still work I've forgotten my login to go and get the tool's name :-D) You might not have forgotten your ITO world login - if you have an RSS feed and follow the url the login from that doesn't work. You have to already have logged in via http://www.itoworld.com in your browser before clicking on the url in the email. Or at least that works for me. Ed Ah. I probably did fall foul of that. That's good to know for the future. In the meantime I have reset my login, so can now confirm (what everyone else probably already knew :-) that it's OSM Mapper that I've been using for that. Would still be interested to hear about what other tools I could/should be using :-) Cheers, Adrian. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Monitoring OSM changes (was Re: natural=heath)
On 09/01/17 12:50, Andy Townsend wrote: More seriously, edits are public, and feeds such as Pascal Neis's, Whodidit and OsmCha allow monitoring of changes in an area, so if you see something that "looks wrong" please do investigate and contact the user about it. Is there a good introduction to those sorts of feeds anywhere? I did set up some changes-in-a-given-area RSS feeds from ITOworld years ago (I'd explain what they are better, but while the feeds still work I've forgotten my login to go and get the tool's name :-D) I'm wondering (and there are often hints, like Andy's comment above, that such tools exist) if there are better/more tools these days to: 1) Keep an eye on all changes for a given geographic area 2) Watch for all changesets that use a given tag (obviously that'd be too much of a firehose for some tags, but for others it'd help people keep an eye on particular sorts of edits) Cheers, Adrian. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Missing Maps humanitarian mapping party in Liverpool on Thurs eve
Hi Frederik, On 14/11/16 14:29, Frederik Ramm wrote: Hi, On 11/14/2016 01:08 PM, Adrian McEwen wrote: No experience necessary, Also compare Pierre Beland's message about "no experience necessary" here https://lists.openstreetmap.org/pipermail/hot/2016-November/012673.html (tl;dr if you advertise "no experience necessary" you better have more than a "short introduction" available for newcomers lest their work may be worthless.) I'm not running the event, just providing a venue (and attending as someone who has some OSM experience). Do you know of any guidelines, tutorials, etc. for either beginners or people running HOT mapathons? Cheers, Adrian. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Missing Maps humanitarian mapping party in Liverpool on Thurs eve
Following on from the HOTOSM mapping party advertised here a couple of months back there's a follow-up one happening this week. Margaux, who organised the first one, is running another this Thursday at DoES Liverpool <http://doesliverpool.com>, from 6:30pm. The Missing Maps project is a global initiative to let people with spare time and a computer help out with humanitarian aid without having to travel to where the aid is being delivered, by doing bits of mapping from satellite imagery to build up maps for those on the ground to use. No experience necessary, I expect Margaux will give a short intro talk about the project, and then we'll be doing some mapping. Bring a laptop (and a mouse might be useful, given the sort of editing you end up doing). Sign up at <https://www.eventbrite.co.uk/e/missing-maps-in-liverpool-tickets-29078159558>. Cheers, Adrian. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] Compression on Overpass API
On Sun, 6/11/16, Dave F wrote: > Do you have a link to the weeklyOSM article? http://www.weeklyosm.eu/archives/8214#wn326_13274 (Unfortunately it seems the only way to find these links on weeklyOSM is by inspecting the HTML code of the page.) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Compression on Overpass API
I read in a recent weeklyOSM about prototype software for downloading OSM data in PBF format from Overpass. This has prompted me to pass on a tip which may not be widely known: It is possible to obtain about 10:1 compression now on any OAPI or XAPI query by using HTTP compression. This is supported on the German and French instances but not on the Russian instance. I use 'curl --compressed' at the command line to invoke HTTP compression, e.g. (for an area of central London) XAPI query curl --compressed -g -o data.osm https://overpass-api.de/api/xapi_meta?*[bbox=-0.15,51.49,-0.1,51.52] Equivalent OAPI query curl --compressed -g -o data.osm 'https://overpass-api.de/api/interpreter?data=(node(51.49,-0.15,51.52,-0.1);%20<;node(w););out%20meta;' This can greatly speed up the downloading of large datasets. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib
J'ai l'impression que très peu des OSMeurs savent que les positions WGS84 changent d'une année à l'autre. Le déplacement est de 25mm par an (au millimètre près). Ça fait déjà 25cm pendant les dix années d'OSM. C'est à cause du mouvement de la plaque tectonique européenne. Ce changement ne conviendrait pas à ceux qui gèrent le Cadastre, ni aux agences nationales de la cartographie comme l'IGN. Donc les agences européennes ont fait un accord sur le système ETRS. Elles ont pris les coordonnées WGS84 telles qu'elles étaient au 1er janvier 1989. Depuis, les coordonnées ETRS suivent le mouvement de la plaque tectonique. Ce qui fait que la différence entre WGS84 et ETRS est maintenant presque 70cm. La version officielle française de ETRS est RGF93. Les fiches IGN donnent l'impression que WGS84 et RGF93 sont la même chose mais ce n'est pas vrai. Les fiches IGN sont exprimées en RGF93. Comme ça, les chiffres ne changent pas au fil du temps. Le Cadastre, quand il est de bonne qualité, est calé sur RGF93. Donc OSM en France est forcément calé aussi sur RGF93. Moi aussi, j'ai un GPS de haute performance (u-blox NEO-7P avec PPP, pas RTK), et il a fallu déplacer les traces 50cm vers l'ouest et 40cm vers le sud pour accorder avec le Cadastre. Je crois que personne qui a à faire avec OSM, veut penser comment prendre en compte le mouvement des plaques tectoniques. Bien entendu, 70cm n'explique pas un écart de 2,4m. Mais il est clair qu'il y a besoin de savoir quelle est la référence des corrections. La référence du résultat sera la même que la référence des corrections. Dans le cas de mon NEO-7P, les corrections viennent des satellites EGNOS, et la référence est ITRF2011 (le même que WGS84 à quelques centimètres près). L'altitude est toute autre chose parce qu'il y a l'ellipsoïde, puis il y a un modèle du géoïde, puis il y a le zéro de l'IGN. J'ai acheté le NEO-7P chez u-blox https://www.u-blox.com/en/product/evk-7 J'ai mis le GPS en mode PPP (positionnement précis des points). L'inconvénient principal est qu'il y a besoin d'une bonne vue du ciel pour obtenir la meilleure précision, surtout il y a besoin de voir au moins un des satellites EGNOS. Ceux-ci sont en orbite géostationnaire, donc ils sont vers le sud à une hauteur d'environ 35°. L'avantage est que le récepteur est autonome. Comme antenne, j'ai utilisé le Tallysman TW2710 acheté chez Digi-Key. Je trouve cette antenne (et le TW2410) très bonne, elle est très sensible et elle rejette très bien les échos à un nombre impair de reflets. On dit que l'antenne marche mieux montée sur un disque en métal d'un diamètre de 10cm https://www.optimalsystem.de/os.aspx?x=4113 et c'est vrai - j'ai vérifié. L'antenne est montée par un aimant très fort, qui va démagnétiser les pistes magnétiques des cartes bancaires et des tickets de métro, et qui va magnétiser, même peut-être détruire les boussoles électroniques comme dans les smartphones. Je conseillerais d'acheter la version non-magnétique de l'antenne, avec NM dans le numéro du modèle. Celle-ci est montée avec des vis d'un type américain; ce sont les mêmes vis que celles employées pour monter les disques durs 3,5 pouces. Avec une bonne vue du ciel, j'ai obtenu un ECP (CEP en anglais) de 35cm. Et les traces sont belles. Adrian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Bug in iD?
@ Andy Townsend Thank you for the good advice. Fortunately I do speak French. @ all I would be interested to have further views on the replacement of nodes in iD. Adrian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bug in iD?
@ Dave F Almost all of the work on way 341531911 has been done by the user in question. It has taken me a while to look into the details. I agree that what the user has done, also raises issues of quality and good practice. These issues will need to be discussed with the user. But before starting a discussion with the user, it is necessary to know whether 1. to call him out for deliberately misusing iD, 2. to explain to him how he is inadvertently mishandling iD, or 3. to say nothing about the replacement of nodes, if it is a bug in iD. Also, before sending in a bug report, it is necessary to know whether it is a bug. That is why I asked the question about iD. It is recommended to try to preserve history https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history To answer your question about the history of way 341531911 in a bit more detail:- The history of the way is complicated so I am simplifying considerably. User Géovélo split an older way, and the part split off became version 1 of way 341531911. Géovélo did this to add the part split off, to two cycle route relations. Version 1, 13 nodes, 280 m, running east 2015-04-29 User J... (I avoid using his full name) split the way at its second node, so the bulk of the original way continues to exist under a new id. After an editing session on 2015-08-21 he arrived at this: Version 5, 36 new nodes and 2 pre-existing nodes, 250 m, running south Most of the way follows an older way. Over that stretch, the older way has had all its nodes replaced. J... altered the lists of members of four cycle route relations and left one of them broken. And so on, with edits on 2016-01-01, 2016-01-16 and 2016-02-21, extending the way over existing ways, reaching Version 12, 775 nodes of which 8 pre-existing, 6.9km Almost all the nodes of the overlaid ways have been replaced. Finally, I fixed up 1.6km of roads that the way follows, producing Version 13, 771 nodes of which 95 pre-existing and 1 new, 6.9km 2016-03-15 The user's mapping raises a large number of issues: o Two highways overlaid. There should be one highway; the mapper should decide what is its principal characteristic or use and tag accordingly, then add any appropriate tags for additional characteristics or uses. o He has mapped a cycleway along roads where there isn't a cycle track or a cycle lane. o He has mapped a route which includes one-way sections (roundabouts and dual carriageways). How is he going to account for the opposite direction of travel? o Traced from misaligned imagery. o Excessive density of points in some parts of the way. o A flourish or hook at the end of the way, which does not reflect anything on the ground, and the end node tagged 'to be continued' (no note or fixme). The hook raises errors in QA tools (intersecting ways on the same level with no node in common). o In two places the way is overlaid with a second short cycleway, one a bridge, one a tunnel. o The way is a member of two cycle route relations. J... has left both relations broken. o What the user is mapping with this way, should actually be mapped with a cycle route relation. Way 341531911 should be deleted except for two short sections where it does not overlay any other way. This may not be easy to deal with. Adrian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Bug in iD?
A user of the iD editor has added a new way along an existing way, with the two ways sharing the same nodes. In so doing, he has replaced all the nodes of the existing way with new nodes. The old nodes have been deleted. The new nodes are in exactly the same positions as the old nodes. If an old node had tags, the tags are reproduced on the new node. If an old node was a member of a relation, the new node replaces the old node in the relation, with the same position and role. These things would be difficult to do in JOSM. See, for example https://www.openstreetmap.org/changeset/37338712 - 144 nodes deleted https://www.openstreetmap.org/way/280996572/history versions 1 and 2 https://www.openstreetmap.org/way/155392067/history versions 1 and 2 As a result, a good deal of history has been lost. (I have since reinstated some of the old nodes.) I am not familiar with iD, so I am asking, is this 1. A bug in iD, 2. Inadvertent action by the user, or 3. Deliberate action by the user? (The user is French; his name exists in both English and French. If the user needs to be contacted, it may be necessary to raise this on talk-fr.) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Suppression de landuses
Un contributeur a supprimé plusieurs polygones 'landuse'. La plupart, mais pas tous, sont des données Corine (CLC). Voir, par exemple https://www.openstreetmap.org/changeset/37751550 https://www.openstreetmap.org/changeset/37727275 https://www.openstreetmap.org/changeset/37727114 Ici il a supprimé un des quatre 'inner' et le 'outer' d'un multipolygone. https://www.openstreetmap.org/changeset/37726551 Ici il a supprimé deux polygones, dont un était le 'outer' d'un multipolygone avec six 'inner'. La relation multipolygone est tagguée landuse=vineyard. En conséquence, des zones bâties des communes de Florensac, Pomérols et Pinet (34) sont devenues des vignobles dans le rendu principal de la carte (openstreetmap.org). https://www.openstreetmap.org/changeset/37712462 https://www.openstreetmap.org/changeset/37700255 Ici suppression 7 jours après la création. Il y en a peut-être d'autres. Je n'ai pas cherché plus loin dans le passé. Au premier coup d'oeil, les autres changements faits par ce contributeur paraissent raisonnables. Il a même ajouté des tags sur une relation multipolygone (1600920) mais peut-être avec iD on ne voit pas si on taggue une relation ou un chemin. Je ne m'y connais pas vraiment quand il s'agit des landuses. Je souhaite vos avis sur ce que le contributeur a fait. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-dk] Motortrafikvej burde være motorroad=yes?
Nu mente jeg heller ikke at alt skulle presses ned i samme referenceramme. Du har helt at det kan af gode grunde ikke lade så gøre. Men når vi kan, så syntes vi bør prøve. Også er det jo logisk at tildels følge hvad vores naboer gør. Mit eksempel med Svendborg var bare eksempel på hvornår OSM ikke fulgte det regler vi havde, og hvad ideen med det var. Havde ikke set den var fornylig redigeret. Men udover det. En grund jeg har til at ændre noget / tilføje noget, skulle være det eksempel med Odenses Østre Ringvej. Og det baserer sig mest at jeg tilfældigt brugte den for ikke så lang tid siden. Men da jeg ville bruge openstreetmap til at faktisk finde hvilken vej jeg havde kørt, kunne jeg ikke let finde den (er overhovedet ikke stedbekendt på Fyn). Når jeg havde kørt på en vejanlæg med ramper osv, så var min intuition at sådan et vej let ville fremgå på kortet. Derimod er den kun anført som =secondary. Nu skal man selvfølgelig ikke bare gøre den til =trunk bare fordi den skal være mere tydelig (det ville jo være at tagge for renderen). Især eftersom det er tydeligt at vi kun vil bruge =trunk for motortrafikveje. Og her ligger så kerne. Hvis vi reelt har veje i Danmark som har betydende form udover hvordan de officielt er beskrevet så er der værdi i at finde en måde at inkorporere det. Så kan eventuelle alternative kort vise dette. Måske kan vi bare tilføje ekstra tags. Men som diskussionen er fremskredet er jeg mere usikker hvordan og hvornår. Eneste eksempel på et tag der på nogen måde er i nærheden er det forslået tag expressway=yes. Du sigde at vi ikke har noget tertiært vejnet, hvilket er jo sandt nok. Men var også massere kommuner som opdeler vejene i forskellige klasser. For eksempel opdeler Odense deres trafikveje i fordelingsveje og gennemfartsveje. Det har ikke nogen betydning når du sider i bilen og skal finde en rute, men det kan have nogen betydning for hvor vigtig og stor en vej er. Hvilket igen kan indikere hvilken veje der er bedst at tage. Men udmiddelbart må jeg jo nok lade det ligge, da jeg ikke har nogen komplet ide. Og hvis vi begynder at tagge selve anlægsformen af vejene er der mange overvejelser at gøre. 2016-02-16 19:19 GMT+01:00 Rasmus Vendelboe <r.vendelboe+...@gmail.com>: > Jeg kan se jeg skal slå farver i JOSM til igen :). Beklager, du har ret. > Den er rettet af MicDK for 2 uger siden [1]. Vejdirektoratet har ikke > beskrevet noget projekt på strækningen, og statsvejnettet 2015's rapport > viser ikke at der skulle være tale om en motortrafikvej. Har du forhørt dig > hos MicDK før du skrev til mailinglisten > > >>Er en af primær ideerne ved openstreetmap ikke at man laver en global > kort? > Nej da. Vi kan ikke presse alt ned i samme referenceramme og vi bør heller > ikke gøre det. Nomenklaturen i OSM er udlagt efter det britiske vejsystem > og vi divergerer på flere punkter fra den i Danmark. Vi har for eksempel > ikke noget tertiært vejnet. Hvis motorway=yes giver mening i Norge og > Tyskland så er det jo bare godt for dem. Vi skal vel ikke implementere alle > tags bare fordi de er til rådighed og andre bruger dem? > > >>Hvad er svært så at forstå. > Jeg har svært ved at forstå hvad vi opnår ved at implementere din ide. > Hvad er vores case: Hvad vinder vi ved det her? Hvordan gør det OSM bedre? > Opvejer fordelene ulemperne? OSM har jo historisk været et show it, don't > tell it projekt, så meget lange forklaringer plejer ikke at være et godt > tegn :). > > [1] https://www.openstreetmap.org/changeset/36856979 > > Med venlig hilsen > Rasmus Vendelboe > > 2016-02-16 18:36 GMT+01:00 Adrian Kern <tejnk...@gmail.com>: > >> Du tag fejl når du siger den allerede er tagget som =primary. Den går fra >> at være motorway til trunk til primary. Kik efter inde i selve Svendborg, >> det er der den er tagget som =trunk. >> >> Hvorfor? Vi er da ikke underlagt hverken norske eller tyske normer og >>> retningslinjer? >> >> >> Nu må du da holde op. Er en af primær ideerne ved openstreetmap ikke at >> man laver en global kort? Der er en grund til at vi bruger samme tag i >> forskellige lande. Desuden er det jo let fikset ved at give highway=trunk >> et default med motorroad=yes, som Jørgen vist nok gjorde. Lidt koordinering >> med lande nær os gør jo ikke ondt. >> >> Ikke forstået. En motortrafikvej er en kun og kun en motortrafikvej når >>> den er skiltet som sådan. Se færdselslovens §2 stk. 16. Grenåvej i Århus N >>> er af den type 80km/t vej som du beskriver. Det er en sekundærvej. >>> >> >> Hvad er svært så at forstå. At der er veje som ikke er motortrafikveje >> som fordelagtig kunne tagges anderledes end bare =primary, præcis fordi de >> har et anlæg som er større end en normal landevej. Hvorvidt forskellige >> data-brugere s
Re: [Talk-dk] Motortrafikvej burde være motorroad=yes?
Du tag fejl når du siger den allerede er tagget som =primary. Den går fra at være motorway til trunk til primary. Kik efter inde i selve Svendborg, det er der den er tagget som =trunk. Hvorfor? Vi er da ikke underlagt hverken norske eller tyske normer og > retningslinjer? Nu må du da holde op. Er en af primær ideerne ved openstreetmap ikke at man laver en global kort? Der er en grund til at vi bruger samme tag i forskellige lande. Desuden er det jo let fikset ved at give highway=trunk et default med motorroad=yes, som Jørgen vist nok gjorde. Lidt koordinering med lande nær os gør jo ikke ondt. Ikke forstået. En motortrafikvej er en kun og kun en motortrafikvej når den > er skiltet som sådan. Se færdselslovens §2 stk. 16. Grenåvej i Århus N er > af den type 80km/t vej som du beskriver. Det er en sekundærvej. > Hvad er svært så at forstå. At der er veje som ikke er motortrafikveje som fordelagtig kunne tagges anderledes end bare =primary, præcis fordi de har et anlæg som er større end en normal landevej. Hvorvidt forskellige data-brugere så vil bruge dem er jo lidt et andet spørgsmål. Hvad den tagging burde være er jeg stadig uklart på, og derfor lægger jeg op til diskussion, og hvorfor jeg taget eksempel i den brug vi allerede har. Det står jo klart at du mener vi bare skal fikse vejen i Svendborg, og det er jo let gjort. 2016-02-16 18:15 GMT+01:00 Rasmus Vendelboe <r.vendelboe+...@gmail.com>: > >>Så ifølge de regler vi har burde den ændres til highway=primary > (eftersom det er en primær rute) + bicyle=no + foot=no. > > Når jeg kigger på den, så er den allerede tagget (korrekt) som > highway=primary. Vi har derimod det modsatte problem. Den del af vejen som > er på Langeland er, efter min bedste hukommelse, netop motortrafikvej men > er pt. tagget som hovedvej. > > Med venlig hilsen > Rasmus Vendelboe > > 2016-02-16 17:53 GMT+01:00 Adrian Kern <tejnk...@gmail.com>: > >> >> Ligesom med motorveje handler det ikke om, hvad man selv eller >>> forskellige myndigheder synes, men udelukkende om, hvordan vejen er skiltet. >> >> >> Vejen i Svendborg skiltes udelukket med ophøring af motorvej, ifølge de >> få Mapillary billeder der eksisterer. Så selvom den rent anlægningsvis har >> 2 spor og har påkørselsramper, er det ikke andet end en landevej (må jeg >> antage). Der er desværre ikke Mapillary billeder fra den modsatte retning. >> >> Så ifølge de regler vi har burde den ændres til highway=primary (eftersom >> det er en primær rute) + bicyle=no + foot=no. Jeg ved ikke helt hvor vild >> jeg er med den ide. Når man kikker på et kort er det jo dejligt at få >> påpegede de veje som er større og hurtigere end andre. Generelt har >> landeveje og motortrafikveje samme maks hastighed, men motortrafikveje er >> typisk hurtigere givent de har langt færre overskæringer (kryds og >> sideveje). Når vi nu har vej som ikke har de overskæringer, men af diverse >> grunde ikke skiltet som motortrafikvej, så er det stadig dejligt at blive >> gjort opmærksom på den på et kort. >> >> Jeg ved ikke helt hvad det bedste ville være. En mulighed er at bare lade >> den være som den er (highway=trunk). Alternativt kunne man tagge den >> (highway=trunk + motorroad=no). Eftersom vi stadig har de bicycle=no + >> foot=no defaults på =trunk behøver vi ikke nærmere at tagge den (eftersom >> motorroad=no på ingen måde er en tilkendegivelse af at cykler og fodgængere >> må benytte den). >> >> ___ >> Talk-dk mailing list >> Talk-dk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-dk >> >> > > ___ > Talk-dk mailing list > Talk-dk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-dk > > ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Motortrafikvej burde være motorroad=yes?
> Ligesom med motorveje handler det ikke om, hvad man selv eller forskellige > myndigheder synes, men udelukkende om, hvordan vejen er skiltet. Vejen i Svendborg skiltes udelukket med ophøring af motorvej, ifølge de få Mapillary billeder der eksisterer. Så selvom den rent anlægningsvis har 2 spor og har påkørselsramper, er det ikke andet end en landevej (må jeg antage). Der er desværre ikke Mapillary billeder fra den modsatte retning. Så ifølge de regler vi har burde den ændres til highway=primary (eftersom det er en primær rute) + bicyle=no + foot=no. Jeg ved ikke helt hvor vild jeg er med den ide. Når man kikker på et kort er det jo dejligt at få påpegede de veje som er større og hurtigere end andre. Generelt har landeveje og motortrafikveje samme maks hastighed, men motortrafikveje er typisk hurtigere givent de har langt færre overskæringer (kryds og sideveje). Når vi nu har vej som ikke har de overskæringer, men af diverse grunde ikke skiltet som motortrafikvej, så er det stadig dejligt at blive gjort opmærksom på den på et kort. Jeg ved ikke helt hvad det bedste ville være. En mulighed er at bare lade den være som den er (highway=trunk). Alternativt kunne man tagge den (highway=trunk + motorroad=no). Eftersom vi stadig har de bicycle=no + foot=no defaults på =trunk behøver vi ikke nærmere at tagge den (eftersom motorroad=no på ingen måde er en tilkendegivelse af at cykler og fodgængere må benytte den). ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Motortrafikvej burde være motorroad=yes?
e nødvendig på disse. > > Jeg har også lige forsøgt mig med > > http://www.openstreetmap.org/directions?engine=graphhopper_bicycle=55.4059%2C9.3063%3B55.4427%2C9.3324#map=14/55.4243/9.3118 > på et stykke motortrafikvej hvor bicycle=* ikke specifikt er angivet og > det ser > ud til at virke udmærket. > > Mvh Hjart > > Torsdag den 11. februar 2016 00:29:40 skrev Adrian Kern: > > Så vidt jeg kan se så bruger vi ikke tagget motorroad=yes i Danmark. > > Desuden bruger vi highway=trunk kun til motortrafikveje. Det ser ud til > at > > andre lande bruger highway=trunk en smule mere generelt. > > > > Jeg vil ikke umidbart ændre på hvornår vi bruger highway=trunk. Men vi > kan > > stadig tagge alle dem med motorroad=yes. Så behøver vi heller ikke at > > specificere nærmere at cyckler og fodgængere ikke på bruge dem. Desuden > vil > > så også nærmere os lidt mere hvordan andre lande tagger > > > ___ > Talk-dk mailing list > Talk-dk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-dk > ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[Talk-dk] Motortrafikvej burde være motorroad=yes?
Så vidt jeg kan se så bruger vi ikke tagget motorroad=yes i Danmark. Desuden bruger vi highway=trunk kun til motortrafikveje. Det ser ud til at andre lande bruger highway=trunk en smule mere generelt. Jeg vil ikke umidbart ændre på hvornår vi bruger highway=trunk. Men vi kan stadig tagge alle dem med motorroad=yes. Så behøver vi heller ikke at specificere nærmere at cyckler og fodgængere ikke på bruge dem. Desuden vil så også nærmere os lidt mere hvordan andre lande tagger ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[Talk-GB] Updating maps
I made a change to openstreetmap.org last month, to correct Calverley Park Gardens in Tunbridge Wells to be the B2249 (previously showing as the A264). Whilst this appears on the map when I open it, when I look at other maps based on openstreets, such as http://www.kenttraffic.info/, it's still showing the old information. When will that map get changed? Adrian ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Updating maps
Thanks for the fast response Stuart. I can see on your website that once you go to the right level, the road shows as the B2249, which is good. Kent Traffic shows it as the A264 at all zoom levels. I'll contact KCC to see when they propose to update. On 4 January 2016 at 10:55, Stuart Reynolds < stu...@travelinesoutheast.org.uk> wrote: > Hi Adrian, > > It rather depends on where they are getting their map tiles from, and how > often those are updated. Users are really supposed to generate their own. > > Here at traveline south east (www.travelinesoutheast.org.uk), for > example, we have two different sets of tiles, representing different zoom > levels and delivered from different servers. At our default level you get > presented with a map tile which is only updated annually. There is a very > good argument to say that the default should be more often, but I digress. > For Calverley Park Gardens, it shows the old road designation right now. > The two levels of zoom below that are delivered from a tile server that is > updated overnight and re-tiled on the fly. So if you zoom in then you see > your edit. > > Personally, I would rather re-tile it all. However, as you zoom out you > get fewer tiles, but there is more data to crunch to produce them - and > that can leave us not only taking a while to produce the tiles, but also > the time to then transfer large batches of data to the servers. So we made > a design decision to do it the way we have. > > I’m sure that you will find that Kent Traffic has similar policies. But to > know what they are, you would have to ask them. > > Regards, > Stuart > > ---- > Stuart Reynolds > for traveline south east & anglia > > > > On 4 Jan 2016, at 10:35, Adrian Berendt <adrian.beren...@gmail.com> wrote: > > I made a change to openstreetmap.org last month, to correct Calverley > Park Gardens in Tunbridge Wells to be the B2249 (previously showing as the > A264). Whilst this appears on the map when I open it, when I look at other > maps based on openstreets, such as http://www.kenttraffic.info/, it's > still showing the old information. > > When will that map get changed? > > Adrian > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > > > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[OSRM-talk] osrm-prepare issue
Hi,I have an issue with osrm-prepare. osrm-prepare will only run for a few seconds and output the following: ./osrm-prepare switzerland-exact.osrm[info] Input file: switzerland-exact.osrm[info] Restrictions file: switzerland-exact.osrm.restrictions[info] Profile: profile.lua[info] Threads: 4[info] Generating edge-expanded graph representation[info] - 2166 restrictions.[info] Importing n = 2793814 nodes[info] - 2056 bollard nodes, 2547 traffic lights[info] and 2888574 edges[info] Graph loaded ok and has 2888574 edges[info] Removing graph geometry while preserving topologySegmentation fault: 11When trying to run OSRM afterwards with "./osrm-routed switzerland-exact.osrm" I get:[info] starting up engines, v4.7.1-1-g40443d1[info] populating base path: switzerland-exact.osrm[info] not a regular file[warn] exception: .hsgr not found: switzerland-exact.osrm.hsgrWhy is this? What should I do to overcome this issue?I'm on Mac OSX10.10.3Thanks in Advance for any hintsAdrian ____ Adrian Schmid Projektleiter Fon +41 71 226 12 14 Web http://www.fhsg.ch FHS St.Gallen, Hochschule für Angewandte Wissenschaften Institut IMS-FHS | Rosenbergstrasse 59 | Postfach | 9001 St.Gallen | Switzerland FHO Fachhochschule Ostschweiz ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[talk-au] Re campsites
Greetings all. I think toilets and presence of drinking water should be separate pieces of information easily obvious to any user. While all campsites with drinking water will have toilets, the reverse is often not true in NSW. I was at one last weekend - fairly large and popular ( room for 30 or 40 tents and vans), within 2 hours drive from sydney, and it had no water except for unreliable tank water. ( plenty last weekend lol). http://www.nationalparks.nsw.gov.au/Dharug-National-Park/Mill-Creek-campground/camping This information is of interest to cycle tourists particularly, who need to manage water supplies quite carefully. It is depressing to get to the campsite only to realise you have to cycle another 10ks to get water. So I would suggest the second tier be basic plus toilets without an assumption about water. I do realise cycle tourists are only a small user group and will probably use other more detailed resources though. Cheers Adrian Sent from my iPhone On 3 May 2015, at 10:02 pm, talk-au-requ...@openstreetmap.org wrote: Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: camp sites (Ian Sergeant) -- Message: 1 Date: Sun, 3 May 2015 17:43:11 +1000 From: Ian Sergeant inas66+...@gmail.com To: Warin 61sundow...@gmail.com Cc: OSM - Talk-au talk-au@openstreetmap.org Subject: Re: [talk-au] camp sites Message-ID: CALDa4Y+PKFmM7V+gZDb_aCxgwgLYiUCs24NDcGpTYsL=fey...@mail.gmail.com Content-Type: text/plain; charset=utf-8 On 3 May 2015 at 15:27, Warin 61sundow...@gmail.com wrote: Whatever way it is cut there is a 'responsiblity', and I'd rather see the 'rules' and have the mapper make the choice from local knowledge rather than pass it to some remote person who can only judge it from a yes/no answer. I'm in also in favour of subjective decisions, when we need a subjective decision, to be made close to the source. However, there are some tags that simply aim to group objective facts by applying a ruleset to them. From the description this looks like one of those cases. I look to see what amenity a campsite has, look up the proposal, and decide on a category to assign it to. I can choose to list the amenities too if I want. People might misinterpret the ruleset, and meanwhile, we are losing hard data about the amenities. Is there supposed to be a subjective step that I'm missing? That is you look at all the amenity, and make a judgement call on the category? Ian. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20150503/5e6bbae4/attachment-0001.html -- Subject: Digest Footer ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au -- End of Talk-au Digest, Vol 95, Issue 3 ** ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Re bicentennial trail.
It is great that you guys are mapping this. I have thought about doing some of this trip. As I recall the only way to get maps previously was to buy them from the trail authorities. Also, I think there are some gates that require keys that are available from the trail authorities where it crosses private land. Is the information on how to get this marked on the map? Cheers Adrian. Sent from my iPhone On 01/12/2013, at 11:00 PM, talk-au-requ...@openstreetmap.org wrote: Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: Bicentennial National Trail (Steve Bennett) 2. Wednesday December 11th: meetup with VicRoads (Steve Bennett) 3. Re: data.qld.gov.au explicit permission request (Steve Bennett) 4. Re: data.qld.gov.au explicit permission request (Jason Ward) -- Message: 1 Date: Sun, 1 Dec 2013 00:47:20 +1100 From: Steve Bennett stevag...@gmail.com To: Ian Sergeant inas66+...@gmail.com Cc: Mander Li mander...@yahoo.com.au, talk-au@openstreetmap.org talk-au@openstreetmap.org Subject: Re: [talk-au] Bicentennial National Trail Message-ID: CA+z=q=uuymaxfz0l+v0bafeyke+1sstwt_xjxfqeut7q8gv...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Wed, Nov 27, 2013 at 6:30 AM, Ian Sergeant inas66+...@gmail.com wrote: Hi, It seems the point of the three relations is to identify which parts of the trail are accessible to which categories of users. How do you intend to encapsulate that info? What is the basis for splitting the trail into state sections, and putting three relations into another reln? I don't think relations of relations is well supported, and I can't see the motivation for it here. Hi guys, I noticed the three-way duplication but assumed it was for a different reason: so that, say, a hiking map that looks for route=hiking relations will show the BNT, a mountain bike map that looks for route=mtb will also show it etc. Unfortunately I think this is basically legitimate: if the same route is a hiking, cycling and mountain biking route (and we haven't even done horse riding yet) then it probably needs those duplicates. (FWIW, that's a bit of an if - most of the Victorian section is pretty useless for cycling, and not great for unsupported hiking either.) Btw you can see both the BNT and AAWT on my map, http://cycletour.org - just zoom in a couple of clicks. Steve -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20131201/9d2ad144/attachment-0001.html -- Message: 2 Date: Sun, 1 Dec 2013 00:55:50 +1100 From: Steve Bennett stevag...@gmail.com To: talk-au talk-au@openstreetmap.org Subject: [talk-au] Wednesday December 11th: meetup with VicRoads Message-ID: CA+z=q=sv7ubp7uRS0kOM8DYAX5Ggh95YaasmjwQt5GP8=j9...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi guys, I'm helping organise an open data meetup with VicRoads called Meet the data owners: http://www.meetup.com/Datahack-Melbourne/events/152600552/ The idea is to help build relationships between data consumers (particularly developers) and Victorian government data providers, in this case VicRoads. It's not specifically to do with OpenStreetMap, but I thought some people on this list might have a lot to contribute to the question: what could we do if VicRoads made more of their road and traffic data available? Anyway, if you're in Melbourne on Wednesday week, please RSVP and come along. If it's a success there will be more of these in the future with other Vic gov departments and agencies - some spatial, some not. Steve -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20131201/1931b61d/attachment-0001.html -- Message: 3 Date: Sun, 1 Dec 2013 01:02:47 +1100 From: Steve Bennett stevag...@gmail.com To: Jason Ward jasonjwa...@gmail.com, talk-au talk-au@openstreetmap.org Subject: Re: [talk-au] data.qld.gov.au explicit permission request Message-ID: CA+z=q=sYp-H=rpyguyfugdzdo6hjnrs7h3az9dh8d83-mgj...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi Jason, Nice work - any response? Steve On Fri, Nov 15, 2013 at 2:49 PM, Jason Ward jasonjwa...@gmail.com wrote: Hi everyone, My apologies if this has already
[Talk-de] Deutschland API
Hi, ich arbeite seit einiger Zeit an offenen Daten und bin am Überlegen eine API aufzubauen um diese Daten im geographischen Bezug abrufbar zu machen. Ein erster Schritt war die Erstellung der Webseite zum Download der Gemeinde-/Landkreis-/Bundesland-Grenzen als GeoJson [1]. Diese Daten sind jetzt bereits mit den Einwohnerzahlen und Flächenzahlen angereichert. Ich möchte jedoch weiter gehen und zusätzliche Meta-Daten zu den Regionen ablegen. Beispielsweise die Gemeinde-Homepage, Kontakt E-Mail, Autokennzeichen, Wikipedia-Link, PLZ usw. Die meisten dieser Informationen sind bereits in maschinenlesbarer Form in versch. Datenbanken verteilt. Die Idee ist die Daten in ein einheitliches Format überzuführen und über eine Webseite und REST Schnittstelle verfügbar zu machen. Meine Frage wäre, ob jemand von euch ebenfalls an sowas arbeitet und ob es vielleicht Interessenten gibt eine solche Datenbank gemeinsam aufzubauen. Ich denke, es wäre langfristig sinnvoller ein Teil der Meta-Daten aus OSM in einer separaten Datenbank zu führen. Es gibt zwar schon die Seite deutschland-api.de, aber leider scheinen die Jungs nicht sehr weit gekommen zu sein. Die Seite fokussiert sich eher auf Wahlthemen und ist nicht mehr ganz aktuell. Viele Grüße, Adrian http://blog.opendatalab.de [1] http://opendatalab.de/projects/geojson-utilities/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GeoJson Utilites für den Export von Verwaltungsgrenzen
Hi! Wir haben mal wieder ein neues Tool entwickelt, welches wir mit euch teilen wollen. Es geht um den supereinfachen Export von Verwaltungsgrenzen ins GeoJson Format. Die Daten stammen direkt vom Geodatenzentrum und sind mit den aktuellen Einwohnerzahlen vom statistischen Bundesamt (2013/Q2) angereichert. Damit lassen sich ganz nette Visualisierungen machen, falls jemand von euch mit OpenData etwas rumspielen möchte. Das Tool kann auch ganz leicht bereits vorhandene GeoJson Dateien auf einer Karte darstellen. Dazu könnt ihr einfach die GeoJson Datei in den Browser ziehen (die Datei wird nicht hochgeladen, sondern direkt im Browser verarbeitet). Hier gehts zum Tool: http://opendatalab.de/projects/geojson-utilities/ Oder gleich zum Source-Code: https://github.com/opendatalab-de/simple-geodata-selector Ich habe im OSM Blog gesehen, dass Flooh Perlot die Verwaltungsgrenzen Österreichs aus OSM extrahiert und ins GeoJSON-Format konvertiert hat. @Flooh falls du mitliest, dann wäre es eventuell interessant, deine Daten auch über unser Tool zum Export einzurichten. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ingress 4 OSM
Hi! Ich weiß nicht, ob ihr das neue Virtual Reality/Augmented Reality (wie auch immer) Spiel von Google mitbekommen habt: http://www.ingress.com/ Das Spiel ist im Moment in einer closed-beta Phase und ich bin seit 3 Wochen ein glücklicher Spieler ;) Ohne jetzt zu sehr in die Details einsteigen zu wollen, kurz der Spielablauf: es gibt zwei Parteien, Enlightened und Resistance. Auf der ganzen Welt sind Portale verteilt. Die Portale können irgendwelche Monumente, besondere Gebäude, Skulpturen oder sonstige optisch erkennbare Gegenstände sein. Sobald man sich innerhalb von 30m von einem Portal befindet, kann man mit dem Portal via Android-Smartphone interagieren. Wird ein Portal mit sg. Resonatoren bestückt, kann es mit anderen Portalen verlinkt werden. Sobald drei Portale miteinander verlinkt sind, entsteht eine Fläche. Das gibt dann Punkte für das eigene Konto und sg. Mind-Units für die eigene Partei. Man beginnt auf Level1 und kann zuerst nur Portale mit einer Entfernung von 160m verlinken. Je mehr Punkte man hat umso höher das Level und umso größer die Reichweite der Portale, die man verlinken kann. Das gibt dann natürlich auch eine größere Fläche und mehr Mind-Units. Da es zwei Parteien gibt, gibt es natürlich Waffen um gegnerische Portale zu neutralisieren und selber übernehmen zu können. Langen Rede kurzer Sinn: das Spiel ist echt gut und auch ansteckend. Man kann auf der Arbeit der anderen Spieler aufbauen und auch im Spiel via Chat miteinander kommunizieren. Noch sieht man die anderen Spieler im Spiel nicht, aber das könnte noch kommen. Wenn die Beta-Phase bis zum Frühling/Sommer abgeschlossen sein wird, dann könnte es im Sommer ein Hit werden. Jetzt stellt sich die Frage, ob wir für OSM ein ähnliches Spiel bauen könnten um die Daten zu verbessern. Statt Portale OSM-Bugs oder Gebäude ohne Adressen anzeigen :) Es gibt die Vermutung, dass Google selbst das Spiel nutzt um seinen Datenbestand zu verbessern. Zumindest kann man neue Portale für das Spiel vorschlagen, indem man geogetagte Fotos von Monumenten/Gebäuden einschickt. Habt ihr Ideen, wie man aus unseren Problemstellen eine Art Spiel machen könnte? Viele Grüße, Adrian. Mehr Details zum Spiel: http://en.wikipedia.org/wiki/Ingress_%28game%29 Für Screenshots aus dem Spiel am besten Googles Bildersuche verwenden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [talk-au] cities changed to towns- I made Alice Springs a city.
I agree we need to think about the map, not the rules. look at the first map you see when you type OSM into google. Its a map of europe. It shows London, prague, and warsaw but not paris or berlin. Lisbon but not madrid, budapest but not rome. And here, at a slightly different zoom level we get Sydney, Melbourne, Albury and Cooma but not the nations capital - canberra. In fact, Queenbeyan appears before CAnberra. I've just noticed that Queenbeyan also appears before Alice Springs, for goodness sake. In my opinion, if the guidelines generate these counter intuitive maps , then the guidelines are wrong. I have made Alice Springs a city, but feel free to change it back if this violates some rule. We are map makers, not programmers, which means we interpret the physical world through a cultural lense to make a document that helps others. Embrace subjectivity. The number of people living in an area is only one reason a settlement should show up on a map. I would argue one of the lesser reasons, unless the purpoe of that map is to map population density. cheers, adrian. From: talk-au-requ...@openstreetmap.org Subject: Talk-au Digest, Vol 66, Issue 13 To: talk-au@openstreetmap.org Date: Tue, 11 Dec 2012 12:00:04 + Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. (Paul HAYDON) 2. Re: cities changed to towns (Steve Bennett) -- Message: 1 Date: Tue, 11 Dec 2012 21:37:43 +1100 From: Paul HAYDON cadmana...@live.com.au To: Talk-AU OSM talk-au@openstreetmap.org Subject: Re: [talk-au] cities changed to towns Message-ID: snt002-w16383afc8c960153517deea8c...@phx.gbl Content-Type: text/plain; charset=iso-8859-1 Hi everyone, Firstly, a qualification:I've not read the Wiki on this subject, so this is simply my opinion without the support of guidelines/rules/etc. I believe, having authored/compiled some detail Magellan maps for eXplorist GPSrs this year, that more important than guidelines or rules that are documented, there needs to be a hierarchy in the data. Obviously, a city in Europe will be much larger than one in Australia, and similarly, ours will be much larger than those in more remote countries. And the size differs, not only in population, but also in geographical area (since population densities also vary). For example, let me just describe the east coast of N.S.W., centred on Sydney: I reckon Sydney, Newcastle, and Wollongong are no-brainers - they're cities. But also, Gosford and Wyong on the Central Coast should be classified the same. Now, while I'm sure such places as Parramatta are also cities (I've not verified this, but I'm pretty sure), from a mapping perspective, Sydney is probably all that is needed. So, on a broad view, you will see Sydney, with Newcastle to the north, and Wollongong to the South, as well as Gosford/Wyong midway between Sydney Newcastle. The next level should then be those centres within the metropolitan areas which warrant attention: in Sydney, such places as Strathfield, Parramatta, Penrith, Chatswood, Hornsby, Hurstville Sutherland (plus, I'm sure there are others). IMHO, keeping sight of the end-use (i.e. a map) is more important than strictly applying a rule based purely on numbers (although, when in doubt, these can be helpful). So places like Parramatta might not be classified as cities when in fact they are, while others in more remote parts of our country might be classified, even though they might not be cities. Any thoughts? Cheers,Paul. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121211/1c467a61/attachment-0001.html -- Message: 2 Date: Tue, 11 Dec 2012 22:56:37 +1100 From: Steve Bennett stevag...@gmail.com To: Alex Sims a...@softgrow.com Cc: talk-au talk-au@openstreetmap.org Subject: Re: [talk-au] cities changed to towns Message-ID: CA+z=q=uUgqFsEr+0_pxv8vtj526oEL9PayPKbe=chkmp4mh...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I would want place=city to refer to an urban populated area of at least 100,000 people as per http://wiki.openstreetmap.org/wiki/Key:place#Values I've taken to fixing errors from Geofabrik OSMI and have changed places to match the schema above. Whilst I find hamlet village grate on me
[Talk-de] Geodatenzugangsgesetz
Hi! Das Geodatenzugangsgesetz ist im November geändert worden, so dass jetzt eine Anfrage möglich sein sollte. Der § 11 wurde wie folgt geändert. ALT: § 11 Allgemeine Nutzung Geodaten und Geodatendienste sind vorbehaltlich der Vorschrift des § 12 Absatz 1 und 2 öffentlich verfügbar bereitzustellen. Werden Geodaten über Darstellungsdienste bereitgestellt, kann dies in einer Form geschehen, welche eine Weiterverwendung im Sinne von § 2 Nummer 3 des Informationsweiterverwendungsgesetzes vom 13. Dezember 2006 (BGBl. I S. 2913) ausschließt. http://www.geoportal-bw.de/geoportal/export/sites/default/galleries/download s/GeoZG_BGBl.2009_Teil_I_Nr._8_vom_13.02.2009_S._278.pdf NEU: 11 Allgemeine Nutzung (1) Geodaten und Geodatendienste, einschließlich zugehöriger Metadaten, sind vorbehaltlich der Vorschrift des § 12 Absatz 1 und 2 öffentlich zur Verfügung zu stellen. (2) Geodaten und Metadaten sind über Geodatendienste für die kommerzielle und nicht kommerzielle Nutzung geldleistungsfrei zur Verfügung zu stellen, soweit durch besondere Rechtsvorschrift nichts anderes bestimmt ist oder vertragliche oder gesetzliche Rechte Dritter dem nicht entgegenstehen. Geodatenhaltende Stellen des Bundes stellen einander ihre Geodaten und Geodatendienste, einschließlich zugehöriger Metadaten, geldleistungsfrei zur Verfügung, soweit deren Nutzung zur Wahrnehmung öffentlicher Aufgaben erfolgt. (3) Die Einzelheiten zur Nutzung von Geodaten und Geodatendiensten, einschließlich zugehöriger Metadaten, werden in einer Rechtsverordnung nach § 14 geregelt. http://www.geoportal-bw.de/geoportal/export/sites/default/galleries/download s/GeoZGAendG_07-11-2012_BGBl._I_112s2289.pdf Hat jemand von euch schon Erfahrung damit? Wir sind am Überlegen auf diesem Wege Stadtteilgrenzen abzufragen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodatenzugangsgesetz
Das GeoZG gilt für die Geodaten des Bundes und da gehören Stadtteilgrenzen leider nicht dazu. In einigen Bundesländern ist wohl was geplant, aber die Städte wären daran auch nicht gebunden. Du könntest höchtens so mal anfragen und dabei auf den frischen Wind in Sachen Geodaten verweisen. Frischer Wind ist auf jeden Fall gut. ;) PS: Um welche Stadt handelt es sich (gerne auch als PM) Ich bin im LK Heilbronn und Umgebung aktiv. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren
Vielen Dank für die Hinweise. Douglas-Peucker sieht vielversprechend aus. Werde wohl aber eine Implementierung für Java selber schreiben müssen ;) Viele Grüße, Adrian -Ursprüngliche Nachricht- Von: Ralf Klammer [mailto:ralf_klam...@gmx.de] Gesendet: Dienstag, 4. Dezember 2012 08:10 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren Richtige Libraries gibt es dafür nicht...allerdings gibt es in PostGIS die Funktion ST_Simplify() in der Douglas-Peucker umgesetzt ist...http://postgis.org/docs/ST_Simplify.html Ebenso ist diese Funktion auch in gdal vorhanden...hier mal für Python: http://gdal.org/python/osgeo.ogr.Geometry-class.html#Simplify Laut Dokumentationen soll die Funktion ST_SimplifyPreserveTopology() speziell für Polygone geeignet sein...kann man aber nur bedingt empfehlen. Ich habe letztens auch mitbekommen, dass in den neuesten Mapnik Releases auch Linienvereinfachungsalgorithmen implementiert sind, finde aber gerade den spez. Link nicht mehr...nur das hier: https://github.com/mapnik/mapnik/pull/1385 Grüße Am 03.12.2012 18:49, schrieb Adrian Stabiszewski: Am 03.12.2012 18:21, schrieb Adrian Stabiszewski: Das Ganze ist noch etwas langsam weil halt viele Punkte. Kennt jemand euch noch einen Algorithmus mit dem ich die Anzahl der Punkte in einem Polygon für einen bestimmten Zoom Level optimieren kann? Sprich: Punkte entfernen, wenn sie sowieso nicht mehr zur äußeren Form des Polygons beitragen. Ich würde die Abweichung in Pixeln zwischen drei benachbarten Punkten ausrechnen. Genauer gesagt den Abstand des mittleren Punktes von der Tangente von Start und Ziel. Dazu die Auflösung. Wenn der Abstand weniger als 1 Pixel brauchst Du Dir keine Gedanken machen. Du kannst natürlich auch einen Schwellwert bestimmen. Ansonsten: ggf. Mindestabstand in Pixeln bestimmen. Wenn Punkt nicht dargestellt wird, mit nächstem Zielpunkt weiter. Start beibehalten. Ja, genau. Gibt es sowas schon fertig als Library? ;) ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren
Hi! Dies ist eine technische Frage, aber vielleicht hat jemand von euch schon sowas Ähnliches gemacht. Ich spiele gerade mit einer Karte rum, wo man Gemeinden auswählen kann: http://grundid.de/data/gemeinden/ Das Ganze ist noch etwas langsam weil halt viele Punkte. Kennt jemand euch noch einen Algorithmus mit dem ich die Anzahl der Punkte in einem Polygon für einen bestimmten Zoom Level optimieren kann? Sprich: Punkte entfernen, wenn sie sowieso nicht mehr zur äußeren Form des Polygons beitragen. Für Tipps wäre ich dankbar. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren
Am 03.12.2012 18:21, schrieb Adrian Stabiszewski: Das Ganze ist noch etwas langsam weil halt viele Punkte. Kennt jemand euch noch einen Algorithmus mit dem ich die Anzahl der Punkte in einem Polygon für einen bestimmten Zoom Level optimieren kann? Sprich: Punkte entfernen, wenn sie sowieso nicht mehr zur äußeren Form des Polygons beitragen. Ich würde die Abweichung in Pixeln zwischen drei benachbarten Punkten ausrechnen. Genauer gesagt den Abstand des mittleren Punktes von der Tangente von Start und Ziel. Dazu die Auflösung. Wenn der Abstand weniger als 1 Pixel brauchst Du Dir keine Gedanken machen. Du kannst natürlich auch einen Schwellwert bestimmen. Ansonsten: ggf. Mindestabstand in Pixeln bestimmen. Wenn Punkt nicht dargestellt wird, mit nächstem Zielpunkt weiter. Start beibehalten. Ja, genau. Gibt es sowas schon fertig als Library? ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [talk-au] tagging 4WD and dirt roads - I give up.
Hi, adrian here, yeah don't assume no rpelies means no support - Ive just been waiting for the its time to vote email. Think that the idea for extending tracktype is great. Think that the argument to use is that if OSM wants to be considered global then it is just common sense that there must be a visual and electronic indication that a major road is unsealed or requires a specialised vehicle - there are many places in the world where this is the case. And I think there is nothing to be feared in subjectivity - all mapping is subjective, in the end. Otheriwise we would tag a road with width, surface,colour, construction method, traffic flow, traffic destination, speedlimit etc and ask the renderer to deduce that it is a primary or secondary road. This process has been formalised in the case of most roads by a governemnet agency - but it is still subjective - we are just all so used to it that it seems objective. Subjective information from a local oe experienced traveller - is invaluable and should be embraced - not discouraged. That's why guide books and sketch maps are still widely used in specialist applications - eg bushwalking, skiing, rockclimbing etc. So roll on election day.. Cheers. From: talk-au-requ...@openstreetmap.org Subject: Talk-au Digest, Vol 65, Issue 20 To: talk-au@openstreetmap.org Date: Tue, 13 Nov 2012 12:00:04 + Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: tagging 4WD and dirt roads - I give up. (Michael Kr?mer) 2. Re: tagging 4WD and dirt roads - I give up. (Ian Steer) 3. Re: tagging 4WD and dirt roads - I give up. (Andrew Harvey) -- Message: 1 Date: Tue, 13 Nov 2012 08:49:17 +0100 From: Michael Kr?mer ohr...@gmail.com To: Talk-AU OSM talk-au@openstreetmap.org Subject: Re: [talk-au] tagging 4WD and dirt roads - I give up. Message-ID: CADuOafUiz4=7qa-c0e++lw1zcs-ppghawtvwm2eygxplsn_...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, Well, I'm one of those European countries with almost no unpaved roads - and therefore also think they should be rendered differently. A driver encountering an unpaved road here is usually quite confused if that's really an official road... But looking at some of the older discussions around this (e.g. [1] or [2]) I wouldn't really expect any change to the default rendering anywhere soon. So I wonder if anyone ever considered to provide an own map rendering taking the surface/smoothness/4wd_only into account? As the default rendering doesn't really match the traditional coloring scheme in Germany there's a special German style available ([3]). But I assume the problem is to have enough ressources for this... I didn't entirely follow this thread so I hope this isn't something which came up earlier and which I have missed. Michael - [1] http://lists.openstreetmap.org/pipermail/dev/2011-June/022789.html [2] http://lists.openstreetmap.org/pipermail/talk/2011-January/055961.html [3] http://www.openstreetmap.de/karte.html?zoom=10lat=52.51448lon=13.40603layers=B000TF -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20121113/98cc87a0/attachment-0001.html -- Message: 2 Date: Tue, 13 Nov 2012 17:29:26 +0800 From: Ian Steer ianst...@iinet.net.au To: talk-au@openstreetmap.org Subject: Re: [talk-au] tagging 4WD and dirt roads - I give up. Message-ID: 005101cdc181$6019fbf0$204df3d0$@net.au Content-Type: text/plain; charset=us-ascii I have been following this topic on a casual basis (ie I don't feel passionately about it), but I think that what you have written sounds fine. I guess that you will hear from people that feel passionately against your views, but those that think that what you have written makes sense might form the silent majority. Don't give up - there will always be views at odds with your own. Maybe all the others that think the proposal makes sense should speak up too ! regards Ian - Message: 1 Date: Tue, 13 Nov 2012 10:01:38 +1030 From: David Bannon dban...@internode.on.net To: Andrew Harvey andrew.harv...@gmail.com Cc: OSM Australian Talk List talk-au@openstreetmap.org Subject: Re: [talk-au] tagging 4WD and dirt roads - I give up. Message-ID
Re: [Talk-de] Offene Plattform für Gastronomie / Lizenzfrage
Hi Andreas, danke für das Feedback. Die Sache mit dem Neu Button werden wir gleich implementieren. Lokation aus OSM Karte: Die Möglichkeit einen POI zu setzen würde ich in einer Webseite auf die rechte Maustaste legen. Beim verschieben Karte wird ständig reingezoomt und das ist umständlich weil man so immer wieder an anderen Stellen landet. Wenn der POi gesetzt ist kann man dann nicht mehr weiterreinzoomen mit links und muß mit + oder - reinzoomen. Uns wäre die Lösung mit der rechten Maustaste auch lieber, aber im Moment unterstützt dies die Leaflet Library nicht. Die Übernahme über die Karte wird jedoch definitiv weiter verbessert. Wenn der Restaurant als Punkt innnerhalb eines Gebäudes sich befindet dann wird die Adresse des Gebäudes nicht übernommen. Dies wird leider etwas schwierig. Im Moment können wir Locations von einem Punkt und von einem Gebäude übernehmen. Ebenso werden die Öffnungszeiten, die Küche und die Wheelchair Angaben werden nicht übernommen. Ebenso werden diese Angaben nicht in die OSM-Datenbank geschrieben. Es stimmt, dass wir die Küche und ÖZ von OSM noch nicht übernehmen können. Die Wheelchair Angaben sollten aber funktionieren. Ich werde es noch prüfen. Probleme beim Erkennung von Restaurants: Hier existieren vier Restaurants in einem Gebäude , erkannt wird aber nur eines. http://www.openstreetmap.org/?lat=50.682857lon=10.933792zoom=18; layers=M Diese Locations sehen wie Gebäude im Gebäude aus. ;) Ich habe dies für das nächste Release etwas verbessert, so dass jetzt alle vier Locations zur Übernahme angezeigt werden. Bzgl. dem Login mit OSM wäre es denkbar. Wir werden definitiv Logins mit Twitter, Facebook und G+ einrichten. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GONAM - war: Offene Plattform für Gastronomie / Lizenzfrage
Hi Andreas! Kann ich mich trotzdem beteiligen? Klar, Gonam lässt sich problemlos auch mit einem modernen Browser wie Firefox oder Chrome bedienen. Du kannst gerne Bilder von einer Digitalkamera hochladen. Gib uns einfach Bescheid, wenn etwas nicht wie erwartet funktioniert und wie versuchen es zu verbessern. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Plattform für Gastronomie / Lizenzfrage
Aus unserer Sicht hat ein Bild der Fassade einer Location nicht unbedingt die schöpferische Höhe um sich mit Copyrights zu beschäftigen. Wie ist eure Meinung? sehe ich anders, gerade wenn man die Bilder nicht automatisch aufnimmt (so wie StreetView z.B) sondern von Hand, also den Ausschnitt, die Perspektive, den Moment des Auslösens etc. irgendwie doch bestimmt, zumindest manche Eurer User. Eine Erlaubnis des Fotografen braucht ihr auf jeden Fall. Je nach Motiv solltet ihr euch auch mit dem Markenrecht auseinandersetzen. Bspw. wenn ein Markenzeichen das Hauptmotiv des Bildes ist. Uns ist klar, dass nach dem deutschen Urheberrecht jedes Foto auch wenn es nur versehentlich entstanden ist, den Urheberschutz genießt. Wir tendieren im Moment zu der Public Domain Lizenz, da diese den Verwaltungsaufwand reduziert. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Offene Plattform für Gastronomie / Lizenzfrage
Hi! Heute möchte ich euch ein neues Projekt von mir vorstellen, am dem ich mit Felix Ebert zusammen arbeite. Nach meinen bisherigen Projekten wie dem Amenity Editor, Relation Analyzer und dem QA Editor haben wir uns mal den Gastronomie-Sektor vorgenommen. ;) Dazu bauen wir gerade eine offene Plattform für Restaurants, Cafés, Bäckereien und im Prinzip allen Locations auf, bei denen es etwas (warmes) zu Essen gibt. Ziel ist (wie immer) eine möglichst hohe Datenqualität zu erreichen. Dazu erfassen wir sowohl die Öffnungszeiten (+Warme Küche, Happy Hour usw), Speisekarte, aber auch Bilder der Location. Unsere Website ist sowohl via Desktop als auch mobil sehr gut zu bedienen, so dass die Bilder direkt vom Smartphone hochgeladen werden können. Die URL lautet http://gonam.de. Wir stellen unsere Daten unter die ODBL und haben auch eine direkte Integration mit OSM eingebaut. Dadurch können bereits vorhandene Locations von OSM nach Gonam übernommen werden, wie auch neue Locations von Gonam nach OSM transferiert werden. Im Moment haben wir den ganzen Landkreis Heilbronn und die unmittelbare Umgebung manuell erfasst (ca. 1200 Locations) und dabei ca. 25% der Locations mit Bildern und ca. 50% mit Öffnungszeiten versehen (siehe http://gonam.de/stats für eine Gesamtübersicht). Wir möchten jedoch nicht automatisiert den ganzen OSM Stand nach Gonam übernehmen, weil wir bei der Erfassung der Daten im LK HN festgestellt haben, dass die Fluktuation bei den Gastronomie-Betrieben doch recht hoch ist und wir uns bei dem Import ganz schnell viele Leichen einhandeln. Ein Teil unserer Strategie ist es, dass die Besitzer der Locations die Plattform als einen guten Ersatz und/oder Ergänzung für ihre (veraltete, flash-basierte) Homepage erkennen und somit ihre Daten selber erfassen und aktualisieren. Durch regelmäßige Benachrichtigungen/Newsletter können wir Anreize schaffen, dass die Besitzer jegliche Änderungen zügig auf der Plattform aktualisieren. Bis es jedoch soweit ist, setzen wir ganz stark auf den Foto-Beweis ;) Und genau bei den Fotos haben wir im Moment noch eine Lizenzfrage: Die ODBL sieht eine separate Database Contents License vor. Wie müsste man jetzt die AGBs bzw. die Contributor Terms formulieren, damit die von den Usern hochgeladenen Bilder zusammen mit der ODBL ein Package ergeben? Es geht uns darum, dass die Daten auch kommerziell genutzt werden können damit sie beispielweise in Navigationssysteme und mobile Assistenzsysteme (Siri, Google Now) integriert werden können. Macht hier die CC-BY Lizenz Sinn oder sollte man besser auf PD setzen? Wir sehen im Moment bei CC-BY einen erhöhten Verwaltungsaufwand, da der Urheber mit dem Bild mitgeführt werden muss. Aus unserer Sicht hat ein Bild der Fassade einer Location nicht unbedingt die schöpferische Höhe um sich mit Copyrights zu beschäftigen. Wie ist eure Meinung? Ihr seid alle natürlich herzlich eingeladen, das Projekt kritisch zu durchleuchten und uns Feedback zu geben. Wir möchten die Plattform total offen gestalten und mit allen möglichen Daten (ÖPNV Haltestellen usw) verknüpfen. Über eine Beteiligung der OSM Community würden wir uns sehr freuen. Falls ihr noch mehr Ideen habt und euch eventuell an einem Startup beteiligen wollt, dann gebt uns einfach Bescheid. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[talk-au] Question about relations
Greetings all. I usually confine my mapping to bush tracks and cycle paths as this is what I am most interested in and is often not available from other sources. With the recent devastation of the base map I am remapping some of my local area, and rapidly realising how little I really understand, so forgive this basic question. I also find the wiki very hard to practically understand as it assumes a level of knowledge that is beyond me. I am interested in mapping/remapping the walking route the great north walk, which is an established relation. My specific question is, when the route passes down only part of a way, say just a few blocks of a longer street, how do you assign the relation to just a few internodes. Is it necessary to split the ways at the nodes and then just assign the relation to the segments between, or is it necessary to create a new way over the top which is just the walking route, or is there some method that is simpler that I have failed to appreciate. I am only able to use the potlach editor. Thanks, and regards, adrian. From: talk-au-requ...@openstreetmap.org Subject: Talk-au Digest, Vol 61, Issue 32 To: talk-au@openstreetmap.org Date: Wed, 25 Jul 2012 06:05:00 +0100 Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: LTUAE (Ian Sergeant) 2. Re: LTUAE (Michael Hampson) 3. Re: Establishing Priorities on the Central Coast (Michael Hampson) 4. Re: LTUAE (Ian Sergeant) -- Message: 1 Date: Wed, 25 Jul 2012 08:18:12 +1000 From: Ian Sergeant inas66+...@gmail.com To: jink...@bigpond.net.au Cc: talk-au talk-au@openstreetmap.org Subject: Re: [talk-au] LTUAE Message-ID: calda4ykrysq4m3uewjmty6p8wlqznbvkjsunttmvea-ddfp...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 But for metroad 10 for example, there were 2 x relations for metroad ten. I expected they were for north and south bound routes as that is the way they appeared to be listed in some other areas I checked so that is what I have done. Put one relation for north and the other for south. If that's not right let me know and I will fix. Not sure how a routing relation works anyway. For the Sydney metroads I have added directional route relations, that use two directional relations for each metroad. This allows the connectivity of the route to be checked quickly during the reconstruction phase, and otherwise does no harm. When we have reached the next stage of maturity we can decide if we want to merge them back into a single route relation with directional elements. So, yes, what you have done is correct. 2. for the road naming where the ref tag for metroad 10 was MR10 I have changed those to network=MR and ref=10. Same for the other roads I have worked on. Not *certain* that is correct though either so if someone could enlighten me would be good thanks That is correct. See the Australian tagging guidelines in the wiki. 3. state highway 29 continues from boundary street along pacific highway and then along delhi road, which makes that small section of the pacific highway sh29 *and* mr1. what should I use to reflect that? It can be part of both route relations. Just my own view on the redaction process. No issue with people who declined the licence agreement. However it was annoying for me to see one of the very first things I used for practice vanish in a puff of smoke. It was just a building outline, a coles supermarket. I named it, put in the opening hours, telephone number, full address details eg addr: city: etc etc. I turned it into a thing of beauty by entering approx 10 odd pieces of information, just for practice and learning. I thought it a bit harsh just because someone traced a building roof everything I added went as well. Tracing the building would have taken less than a minute. I spent 40 minutes researching and entering that extra detail on that single item. Your change sets are still available. You should be able to at least refer to the info you have added. And yes, the loss of data in this way is the hardest. One person just traces from an aerial and then does not agree. Others survey, add cycle facilities, names etc that are lost to OSM. I don't know if it still possible to better use some of this unattached data in the database down the track. Ian -- next part -- An HTML
Re: [talk-au] relations
Thanks, fellas, I had worried that splitting ways would cause trouble with route finding etc as one street would become 2 adjoining streets with the same name. Regards, adrian From: talk-au-requ...@openstreetmap.org Subject: Talk-au Digest, Vol 61, Issue 34 To: talk-au@openstreetmap.org Date: Wed, 25 Jul 2012 12:00:07 +0100 Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: Question about relations (SomeoneElse) 2. Re: Redaction recovery (Leon Kernan) 3. Re: Question about relations (John Henderson) -- Message: 1 Date: Wed, 25 Jul 2012 07:38:47 +0100 From: SomeoneElse li...@mail.atownsend.org.uk To: talk-au@openstreetmap.org Subject: Re: [talk-au] Question about relations Message-ID: 500f9477.6050...@mail.atownsend.org.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Adrian Plaskitt wrote: My specific question is, when the route passes down only part of a way, say just a few blocks of a longer street, how do you assign the relation to just a few internodes. Is it necessary to split the ways at the nodes and then just assign the relation to the segments between, or is it necessary to create a new way over the top which is just the walking route, or is there some method that is simpler that I have failed to appreciate. I'd split the way, like this: http://www.openstreetmap.org/browse/way/141369518 Here the end of Mandalay Beach Road has been split and the part of the road that belongs to the walking route has been added to the walking route relation ( http://www.openstreetmap.org/browse/relation/400098 in this case). The result looks like this on a map designed to show long distance hiking routes: http://hiking.lonvia.de/en/?zoom=17lat=-35.00144lon=116.53484 Cheers, Andy -- Message: 2 Date: Tue, 24 Jul 2012 21:35:34 +1000 From: Leon Kernan lker...@gmail.com To: talk-au@openstreetmap.org Subject: Re: [talk-au] Redaction recovery Message-ID: 18353cab-6f82-4d09-a7f4-5031dfbc3...@gmail.com Content-Type: text/plain; charset=iso-8859-1 Don't worry too much about the Hume, it's almost fixed as far as i can tell. I think I fixed the last issue affecting routing between Melbourne and Sydney tonight. (hopefully) South west sydney is full of broken roads. I'm not too familiar with central Sydney but if a local could take a look, i'm not game to get too far into that mess. If you need a change, Adelaide is also a huge mess. On 24/07/2012, at 8:34 PM, Michael Hampson wrote: Hi Brian, Good have you on board Brian. Take a look at the Hume Hwy and M5 motorway if you get a chance. Both head south west out of Sydney. Regards, Michael On 24/07/2012 8:23 PM, Brian Prangle wrote: Hi All I can give assistance retracing roads from bing concentrating on motorways and primary roads - I've made a start in South Sydney. Let me know if there's anywhere more urgent. I map mostly in Birmingham UK wher we're now pretty complete and are mostly tracing buildings from bing and addressing which is slow tedious work - so this provides a bit of welcome relief. It also reminds me of my visit to Oz 4 years ago - might even revisit some favourite places virtually! Regards Brian ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-au/attachments/20120724/5b340688/attachment-0001.html -- Message: 3 Date: Wed, 25 Jul 2012 16:16:01 +1000 From: John Henderson snow...@gmx.com To: Adrian Plaskitt adrianplask...@hotmail.com Cc: talk-au@openstreetmap.org Subject: Re: [talk-au] Question about relations Message-ID: 500f8f21.2090...@gmx.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 25/07/12 16:07, Adrian Plaskitt wrote: Greetings all. I usually confine my mapping to bush tracks and cycle paths as this is what I am most interested in and is often not available from other sources. With the recent devastation of the base map I am remapping some of my
Re: [OSM-Talk-ZA] M1 looks weird
Hi talk-za, Speaking of the M1, I know that at least part of it is named the De Villiers Graaff Motorway. Does anyone know what section that name applies to? The whole thing from the end of the Golden Highway all the way to Buccleuch Interchange? Or maybe from the CBD to Buccleuch? Cheers, Adrian On 22 July 2012 02:40, David Richfield davidrichfi...@gmail.com wrote: OK, done. http://www.openstreetmap.org/browse/changeset/12423389 David ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-za ___ Talk-ZA mailing list Talk-ZA@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-za
[OSM-legal-talk] Some questions about using ODbL Produced Work maps in Wikipedia
Hi legal-talk, I have a couple of questions about the use of map images, which I understand to be ODbL Produced Works, in Wikipedia. I've tried to find answers on the OSM wiki but I haven't seen anything addressing them. 1. The attribution requirement. ODbL says: 4.3 Notice for using output (Contents). Creating and Using a Produced Work does not require the notice in Section 4.2. However, if you Publicly Use a Produced Work, You must include a notice associated with the Produced Work reasonably calculated to make any Person that uses, views, accesses, interacts with, or is otherwise exposed to the Produced Work aware that Content was obtained from the Database, Derivative Database, or the Database as part of a Collective Database, and that it is available under this License. Now the usual way to provide attribution notices on Wikipedia images is to include them on the File page about the image (for example http://commons.wikimedia.org/wiki/File:Rondebosch_OSM_map_small.svg) but not in every article where the image is used. A plain reading of the license text seems to indicate that that would not be enough, as readers who view the map on the article would not see the notice. Do we really have to include the full notice Contains information from OpenStreetMap, which is made available here under the Open Database License (ODbL) in the caption of every use of an OSM-derived map in a Wikipedia article? 2. Derived databases. I have produced maps like http://commons.wikimedia.org/wiki/File:Namibia_rail_network_map.svg from OSM data (in that case the OSM data was only used for the railway lines, not for the basemap). To do so I downloaded a particular set of relations from the OSM API, ran a script to convert them to a shapefile, and then another script to generate the map. By downloading these relations and then converting them to a shapefile have I created a Derivative Database? And by uploading the map to Wikimedia Commons have I Publicly Used this database? Does this trigger section 4.6, requiring me to offer the Derivative Database to any recipient of the map (the Produced Work)? Thing is, in the past I have generally deleted these shapefiles when I'm done. If section 4.6 applies, am I now also obliged to keep these forever in case someone requests a copy? Or is it sufficient to say download relations with the following tags in the following bounding box? There seems to be a confusing relationship between section 4.4.c, which says: A Derivative Database is Publicly Used and so must comply with Section 4.4. if a Produced Work created from the Derivative Database is Publicly Used. and section 4.5.b: Using this Database, a Derivative Database, or this Database as part of a Collective Database to create a Produced Work does not create a Derivative Database for purposes of Section 4.4 Which of these clauses applies to my scenario? 3. Subsequent reuse. In the above case, if necessary I can still at least keep a copy of the shapefile and hand it out on request. But, having uploaded the map to Wikimedia Commons, does section 4.6 apply to others who reuse the map? They don't have access to the Derived Database in the first place. If I release the map as CC-BY-SA, are subsequent users required to abide by anything more than the regular attribution requirements of that license? Thanks, Adrian Frith ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Some questions about using ODbL Produced Work maps in Wikipedia
Hi again, On 21 July 2012 20:10, Frederik Ramm frede...@remote.org wrote: On 21.07.2012 18:19, Adrian Frith wrote: Do we really have to include the full notice Contains information from OpenStreetMap, which is made available here under the Open Database License (ODbL) in the caption of every use of an OSM-derived map in a Wikipedia article? I don't know if the legal requirement is for having the attribution directly visible but even if it is, it would be ok to have it in the bitmap rather than in the caption. Would it be a reasonable approach to mention OpenStreetMap (linked to the Wikipedia article on OSM) in the caption and then include the full ODbL notice on the file page, do you think? 3. Subsequent reuse. In the above case, if necessary I can still at least keep a copy of the shapefile and hand it out on request. But, having uploaded the map to Wikimedia Commons, does section 4.6 apply to others who reuse the map? No. The Produced Work you create is uploaded to Wikipedia under CC-BY-SA and that's all that counts. CC-BY-SA would not allow additional conditions (e.g. the making available of a source database) anyway. The Created from OdBL-licensed OSM data available here that you have to add to your Produced Work becomes, in the terms of CC-BY-SA, a copyright notice that the CC-BY-SA user is required to keep intact but that's all they have to do. Does this mean that, in my scenario, the only recipient to whom I have an obligation under ODbL sec. 4.6 is the Wikimedia Foundation? Everyone else who receives it receives it from WMF under CC-BY-SA and they have no claim on me? Thanks, Adrian ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Some questions about using ODbL Produced Work maps in Wikipedia
Hi, On 21 July 2012 21:04, Frederik Ramm frede...@remote.org wrote: On 21.07.2012 20:44, Adrian Frith wrote: If it were any different, you could team up with a co-publisher, publish your ODbL Produced Works to him and he forwards them to the world without you ever having to release anything. It would be a loophole that demands quick fixing ;) Well, that was exactly what came to mind. ;) I have a further question which follows from this. I'm happy to put the OSM extracts behind my maps up on my website in future. But if I upload OSM-derived maps from Wikipedia under CC-BY-SA, with a link to the derived shapefiles on my website, and then at some point in the future I lose the derived shapefiles in, say, a hard disk failure, what happens? I can't comply with the ODbL requirements, because I no longer have the Derivative Database - but I can't force Wikimedia to take them down either, because they are entitled to distribute them under the CC-BY-SA license. Cheers, Adrian ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Relation Analyzer im neuen Gewand
Hi Henning. wäre es möglich, dass du noch ein Datum anzeigst, wenn du eine Relation aus dem Cache analysierst. Ich verwende im Moment eine Cache-Implementierung die total transparent ist, sprich mein Tool weiß nicht, ob die Relation aus dem Cache kommt oder nicht. Dies hat Vorteile bei der Konfiguration. Im Prinzip lässt sich herausfinden ob die Daten aus dem Cache kommen, aber dann müsste ich den Cache extra dafür fragen und somit zusätzliche Abhängigkeiten in Kauf nehmen. Ich glaube, im Augenblick ist die Ladezeit der Seite der beste Indikator ob die Relation aus dem Cache kommt oder nicht. Ist sie 3 Sekunden, dann kommt sie definitiv aus dem Cache ;) Ansonsten ein guter Vorschlag. Ich werde mir die Funktion für die nächste Update-Runde vormerken. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer Bemerkungen
Date: Thu, 14 Jun 2012 14:36:34 +0200 From: Wolfgang Barth wolfg...@barthwo.de To: talk-de@openstreetmap.org Subject: [Talk-de] Relation Analyzer Bemerkungen Message-ID: 4fd9dad2.8050...@barthwo.de Content-Type: text/plain; charset=ISO-8859-15; format=flowed Ich habe aus Versehen einen Suchbegriff in Feld Relation eingegeben. Dann kommt eine ziemlich harte technische mehrzeilige Fehlermeldung. Vielleicht kann man die noch etwas verschönern. Sicher und vielen Dank für den Hinweis. Wird demnächst verbessert. Dann habe ich nach dem Saar-Hunsrück-Steig gesucht mit Suche: Saar-Huns und Relation Type Route. Da kommt der Steig auch zweimal (zwei verschiedene Varianten), aber der Name in der Liste für 2167175 ist veraltet. Beim Analysieren selbst kommt der richtige Name mit Variante Trier. Kann es sein, daß der Suchindex seit Wochen nicht mehr neu aufgebaut worden ist? Wie oft passiert das? Der Index ist von Mitte Mai. Dies ist auch auf der ToDo Liste, so dass die Relationen immer aktuell sind. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation Analyzer im neuen Gewand
Hi! Der Relation Analyzer hat ein neues Gesicht dank Bootstrap bekommen. http://ra.osmsurround.org Darüber hinaus wurden auch ein paar Erweiterungen und Detailverbesserungen durchgeführt: - verbesserte Suche nach Teilbezeichnungen von Relationen - direkte Suche nach ID oder Name aus der Menüzeile heraus - automatische Vorschläge von typischen Werten in der Suchmaske bei den Feldern Network, Route, Relation Typ und Operator. - bessere Farben bei der Way-Verteilung der Hauptstraßen - Analyse auf Karte jetzt mit Leaflet Library und direktem Zoom auf der gesamte Relation - NEU: Höhenprofil bei A nach B Relationen, die lückenlos sind. Funktioniert nur, wenn der RA intern die Relation als einen Pfad erzeugen kann. Das Profil wird grob aus SRTM Daten extrahiert. Beispiel: http://ra.osmsurround.org/analyzeRelation?relationId=2199113 Screenshots: https://plus.google.com/104853427339662862228/posts/gBSvRWdXHxo Ich bin am Überlegen im RA die Möglichkeit einzubauen, Tags direkt zu bearbeiten. Wie dies funktionieren soll, kann man beim Klick auf den Button Alle Tags anzeigen sehen. Die Idee ist, kleine Tippfehler oder fehlende Tags sofort korrigieren zu können. Auch die Möglichkeit eine Relation zu löschen könnte ich einbauen um beispielsweise doppelte Relationen zu entfernen. Hierzu hätte ich gerne etwas Feedback, ob das sinnvoll bzw. gewünscht ist. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer im neuen Gewand
Hi! Auch die Möglichkeit eine Relation zu löschen könnte ich einbauen um beispielsweise doppelte Relationen zu entfernen. Dazu ist mir folgendes eingefallen: eine Art Suche nach überlappenden Relationen. Ich denke an eine Funktion die z.B. alle Relationen liefert welche zumindest x% der selben Wege/Knoten beinhaltet wie die ausgewählten Relation. Das könnte für's Cleanup ganz hilfreich sein. Die Idee klingt interessant, aber total out of scope beim RA. Dazu müsste man die ganze DB abgrasen. Danke für die Relation mit den Voids (Höhe -32768). Ich habe selber nach Beispielen gesucht, aber keine gefunden. Habe das Problem korrigiert. Jetzt ist es eine angenehme Abfahrt auf 53km ;) Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online Quality Assurance Editor
Hi! Ich habe den QA Editor noch etwas für Smartphones verbessert. Das Editor-Popup erscheint jetzt Vollbild und es gibt eine Autocomplete Funktion für die Straßennamen aus der Umgebung. Damit sollte das Erfassen von Adressen zum Kinderspiel werden. Darüber hinaus ist der Editor jetzt auch auf Deutsch verfügbar. Hier ein paar Screenshots wie der Editor auf einem Android aussieht: https://plus.google.com/104853427339662862228/posts/M699buaXAiA Für den Relation Analyzer steht auch eine neue Funktion an: https://plus.google.com/104853427339662862228/posts/9y4TWVeDsPw Viele Grüße, Adrian. Message: 4 Date: Tue, 05 Jun 2012 22:24:09 +0200 From: Roland Olbricht roland.olbri...@gmx.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Online Quality Assurance Editor Message-ID: 1418929.KJzdcs2zvy@roland-latitude-e5520 Content-Type: text/plain; charset=utf-8 Bei hohen Auflösungen kann es helfen, das Browserfenster zu verkleinern. Der Editor versucht immer den sichtbaren Ausschnitt im Fenster downzuloaden. Ich habe leider keinen Einfluss auf den Server und wie viel Daten er liefert. Mirror ! oder eine Auswahl-Option für den Download-Server. Damit kannst Du auch noch den Hauptserver entlasten. Generell lässt sich der Editor so einstellen, dass er die Overpass API nutzt. Da ich als Betreiber der Overpass API daran interessiert bin, den Service zu verbessern, wäre bei Server-Fehlern ein kurzer Report mit - genauer Uhrzeit - möglichst genauen Koordinaten hilfreich. Dann kann ich zumindest vom Log her sagen, was auf dem Overpass- Server passiert ist. Heute morgen hat es beispielsweise ein Problem mit Überlast durch Anfragen von einer iOS-App gegeben, bis ca. 10h08. Je nach Uhrzeit könnten andere Ausfälle darauf zurückzuführen sein. Oder es ist ein echter Bug. Dann interessiert es mich sehr. Durch Fehlerberichte habe ich bereits mehr als ein halbes Dutzend Bugs beseitigen und so den Service nahezu frei von bekannten Bugs halten können. Viele Grüße, Roland -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ende Talk-de Nachrichtensammlung, Band 71, Eintrag 14 * ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online Quality Assurance Editor
Hi! Am 5. Juni 2012 08:33 schrieb Rainer Kluge rklug...@web.de: Die Meldung kommt nicht systematisch sondern bei dem von mir angegebenen Ausschnitt etwa jedes zweite mal. Ich vermute, dass der Server, von dem die OSM-Daten geholt werden, eine Begrenzung nach Client/Volumen/Zeit macht. Kann ich bestätigen: __ Error: Internal Server Error Probably the current area is too big for the server. Try to zoom in a little. __ Ich kann nur nicht weiter reinzoomen. :-/ Bei hohen Auflösungen kann es helfen, das Browserfenster zu verkleinern. Der Editor versucht immer den sichtbaren Ausschnitt im Fenster downzuloaden. Ich habe leider keinen Einfluss auf den Server und wie viel Daten er liefert. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Online Quality Assurance Editor
Hi! Auf dem HACK Weekend letztes Wochenende in Karlsruhe wurde der Tracks Editor etwas erweitert, so dass ich mich entschlossen habe ihn zum QA Editor umzubenennen. Es ist jetzt nämlich auch möglich nach Buildings ohne Adressen zu suchen und diese sofort in einer Dialogbox zu korrigieren. Der Workflow ist denkbar einfach: 1. http://editor.osmsurround.org aufrufen 2. Auf Login klicken um sich beim OSM Server zu authentifizieren (Login Daten bleiben im Browser erhalten, so dass dies nur einmal notwendig ist) 3. In die Gegend rein zoomen in der man sich auskennt (alternativ auch über den Locate Me Button automatisch finden lassen) 4. Download OSM Data anklicken. Standardmäßig werden Tracks ohne Tracktype angezeigt. Über das Options Menu können andere Profile aktiviert werden. 5. Gewünschte Objekte bearbeiten 6. Sobald alle Objekte bearbeitet sind, einfach auf Upload changes klicken, Kommentar für den Upload eingeben 7. Fertig Das Tool ist open-source im meinem GitHub account. https://github.com/grundid/tracks-editor Ich freue mich auf euer Feedback und vielleicht den einen oder anderen Beitrag im Source code. Es sollte eigentlich recht einfach sein, weitere Profile hinzuzufügen um nach bestimmten Problemstellen zu suchen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hi! drauf einen kompletten Editor bedienen zu wollen, noch dazu mit den Wurstfingern, macht wenig Freude. Wenn ich aber auf einem Feldweg stehe und einfach nur (taps) Position ermitteln (taps) Daten laden (taps) Weg auswählen (taps) Oberfläche auswählen machen kann, dann senkt das die Hemmschwelle schnell mal was zu erfassen stark. Zumindest meiner Meinung nach. Hierzu gibt es jetzt ein Update. Man kann im Options-Menü auf Show Buildings klicken und dann werden statt Tracks Ways mit der Eigenschaft building=yes angezeigt. Dies ist nur ein Test wegen der Usability. Bei maximaler Zoomstufe kann man die Gebäude durchaus gut treffen. Die Editbox ist noch nicht angepasst. Hierzu ein Screenshot: https://plus.google.com/104853427339662862228/posts/gcTgjMCyKXP Aber eine Idee zu dem Usecase: Da will man auch den Feldweg splitten können wenn man auf dem Acker steht und 'Hier Beton, vorher grade3 und dann kommt grass' eingeben will. Der track ist ja wahrscheinlich xkm lang und wechselt den Belag. Danke für die Anregung. Dies beschäftigt mich auch seit einiger Zeit. Auf einen Knoten genau zu splitten wird es vielleicht schwierig auf dem Touchscreen sein. Meine Idee war, dass der Way automatisch an den Kreuzungen oder an dem nächsten Knoten zu der aktuellen GPS Position gesplittet wird. Beim Splitten von Ways muss man jedoch die ganze Geschichte mit den Relationen berücksichtigen... dies ist recht viel Arbeit. Das geht natürlich über Tags erfassen hinaus. Scheint mir aber unabdingbar wenn man draußen Wege genauer definieren will. ACK. fun Beim Thema surface wird es schwierig mit dem Konsens. Beim korrekten Tagging von grade4-5 Tracks müsste man doch die saisonalen Unterschiede berücksichtigen. Hierzu sollte das surface Tag wie folgt am Beispiel von einem Track grade5 erweitert werden: surface:Jan=ice surface:Feb=light_snow surface:Mar=mud surface:Apr=ground surface:May=light_grass surface:Jun=flowers surface:Jul=grass surface:Aug=high_grass surface:Sep=grass surface:Okt=ground surface:Nov=leaves surface:Dec=snow /fun Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hab schon Wege bei mir gefunden, die ich ergänzen muss. Für die Liste würde ich vorschlagen: artificial_turf, asphalt, cobblestone, compacted, concrete, concrete:lanes, concrete:plates, fine_gravel, grass, grass_paver, gravel, ground, metal, mud, paving_stones, pebblestone, sand, tartan, wood, clay Ok, ich habe die Liste nochmals erweitert. http://tracks.osmsurround.org/ Darüber hinaus habe ich das UI auch für Tablets und Smartphones optimiert. Die Labels der Buttons verschwinden, wenn die Fensterbreite sehr klein wird. Zu guter Letzt ist auch der Locate Me Button verfügbar, der auf die GEO Location API zugreift um sich z.B. unterwegs auf den Feldern direkt lokalisieren zu lassen :) Mit etwas Fingerspitzengefühl bin ich jetzt in der Lage mit einem Smartphone die Tracks direkt unterwegs zu korrigieren. Vielleicht gibt es den einen oder anderen, der den Tracks Editor beim HACK Weekend in Karlsruhe noch etwas mobiler machen will. Ich könnte mir sehr gut eine (Accordion) Liste von Tracks vorstellen, die ich einfach mit dem Finger durchscrollen kann. Die Tracks sind natürlich so sortiert, dass der mir am nächsten liegende ganz oben ist. Beim Klick wird der Track auf der Karte markiert und das Editor-Popup geht auf. Ich werde das Tool bis morgen in meinem GitHub Account online stellen: https://github.com/grundid/tracks-editor Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Ich werfe meine Frage einfach mal ganz frech in die Runde: gibt's eine Chance sowas z.B. auch für die Hausnummernerfassung zu bekommen? vg, Martin Teilweise ist dies mit meinem anderen Tool dem Amenity Editor möglich: http://ae.osmsurround.org Dies funktioniert jedoch nur für POIs. Ich habe mich mit dem Adress-Schema nie auseinander gesetzt, so dass ich nicht weiß, wie die Daten hier auf Straßenebene aussehen. Mit dem Tracks Editor erstelle ich gerade auch eine osm-tools library in Java. Das Lesen und Ändern von Daten in OSM wird damit zum Kinderspiel. (AOuth, Schema usw.) Falls sich jemand der Sache annehmen will, dann kann ich ihn gerne unterstützen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Teilweise ist dies mit meinem anderen Tool dem Amenity Editor möglich: http://ae.osmsurround.org Dies funktioniert jedoch nur für POIs. Kurz getestet: funktioniert auf meinem Smartphone nicht. Ok ok ;) Der Amenity Editor ist schon gut 2 Jahre alt. Für Smartphone war das teil nicht gedacht. Man müsste dem Editor ein Facelift verpassen oder eine integrierte Lösung mit dem Tracks Editor machen. Ich habe mich mit dem Adress-Schema nie auseinander gesetzt, so dass ich nicht weiß, wie die Daten hier auf Straßenebene aussehen. Wenn ich ehrlich bin, mir würde es schon reichen, wenn ich auf ein vorhandenes Gebäude tippen könnte und nur die Hausnummer eingeben kann. Selbst der Straßenname wäre für mich schon nur noch nice-to-have, weil ich das zu Hause am Rechner auch flott machen kann - genauso wie die Gebäude vorab eintragen. Anzeige von Building-Ways klingt recht einfach. Du möchtest einfach alle Building-Ways angezeigt bekommen und dann die Attribute dazu ändern können? Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hi Henning. was mir noch aufgefallen ist: Wäre es möglich die aktuelle Kartenposition und die Ergebnisse zu erhalten, wenn man sich eingeloggt? Oder das man zu Beginn einen Hinweis bekommt, dass man sich erst einloggen soll? Die Kartenposition zu speichern ist kein Problem. Bei den Ergebnissen wird es etwas schwieriger. Ich verwende zum Speichern von Daten den localStorage, den HTML5 Browser zur Verfügung stellen. Das Limit liegt hier bei ca. 5MB. Meine Daten kommen als GeoJSON vom Server. Dies als String in den localStorage zu packen ist kein Problem. Ich habe jedoch noch nicht geschaut, wie viel Daten hier so übertragen werden. Was ist dein Hintergrundgedanke beim Zwischenspeichern der Ergebnisse? BTW: Der Login muss eigentlich nur ein einziges Mal erfolgen, wenn du deinen eigenen Rechner verwendest. Und normalerweise müsste der Login-Hinweis auch angezeigt werden, wenn du das erste Mal versuchst einen Track zu speichern. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hi! Nur ein kurzes Update: das Bearbeiten von Tracks funktioniert jetzt auch direkt aus dem Browser. Login funktioniert über den OSM Server. Man kann die tracktype und surface Eigenschaft setzen. Danach einfach upload changes klicken ;) Viel Spaß: http://tracks.osmsurround.org Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hallo, eine schöne Sache ist das geworden. Bei surface würde ich mir noch die Möglichkeit wünschen, weitere Werte einzugeben. Danke! Welche Werte vermisst du? Ich habe mir an dem Wiki orientiert: http://wiki.openstreetmap.org/wiki/Key:surface Habe die häufigsten Optionen in die Auswahlliste übernommen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tracks Selector wird zum Editor
Hi! Ich bin gerade dabei den Tracks Selector etwas zu erweitern. Die Darstellung und Bedienung wurde daher überarbeitet. Die Tracks werden jetzt bei MouseOver in einer anderen Farbe hervorgehoben. Darüber hinaus bereite ich gerade die Möglichkeit vor, die Tracks auch direkt im Browser bearbeitet zu können. Die JavaScript Seite ist fast fertig, ich muss nur noch die OAuth-Anbindung implementieren. Der Ablauf wird sein, dass man sich die Daten im aktuellen Sichtbereich des Browsers downlädt und dann die Tracks nach und nach bearbeitet. Danach alles auf einen Schlag hochlädt. Die entsprechenden Buttons und Funktionen sind bereits implementiert. http://tracks.osmsurround.org Mir schwebt auch noch vor, das alles Smartphone/Tablet tauglich zu machen. Die Auswahl der Tracks würde dann über eine scrollbare Liste und die Darstellung auf einer verkleinerten Karte erfolgen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation Analyzer zeigt jetzt die Way Verteilung an
Hi! Der Relation Analyzer zeigt jetzt die Verteilung der Ways innerhalb der Relation an. Die Darstellung erfolgt in Form von farblichen Balken, die jeweils dem Anteil der Gesamtlänge der Relation entsprechen. Damit kann man z.B. sehen, ob bei einem Radweg irgendwelche Ways vom Typ motorway enthalten sind. Oder bei Bundesstraßen-Relationen kann man prüfen ob alle Wegs vom entsprechend Typ sind. Beispielsweise enthält B 27 einen Way vom Typ tertiaray: http://ra.osmsurround.org/analyzeRelation?relationId=2064452 Es lässt sich auch der Anteil von unbefestigten Streckenabschnitten ermitteln. Als Beispiel der Skulpturenradweg: http://ra.osmsurround.org/analyzeRelation?relationId=2116072 Bei Relationen, die keine Ways mit Typ highway haben, wird die Darstellung weggelassen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hack-Weekend Karlsruhe und Administrative Grenzen / Hierarchien weltweit
Hi! Mich würde es insgesamt interessieren, ob es an so einem Qualitätsmanagement-Tool Bedarf bzw. Interesse gibt. Sowohl die administrativen Grenzen als auch die Relationen bieten einen guten Ausgangspunkt um Qualitätsmanagement zu betreiben. Ich könnte mir gut ein Tool vorstellen, bei dem man sich z.B. auf ein oder mehrere Landkreis- oder Gemeindegrenzen registriert um über Änderungen benachrichtigt zu werden. Dabei sehe ich vor allem die Funktion, dass man sich über bestimmte Ereignisse in seinem Land-/Gemeindekreis informieren lässt, wie beispielsweise: - ein residential way wurde ohne Namen erstellt - ein track ohne tracktype / surface erstellt - ein amenity ohne Öffnungszeiten / ohne Adresse erstellt usw. Bei Relationen könnte man es ähnlich machen. Mögliche Ereignisse wären: - Relation enthält Lücken - Relation verlängert / verkürzt - Typ der Relation geändert - Relation gelöscht Wie sind eure Meinungen? Gibt es vielleicht schon sowas, ohne dass sich jeder dies mit Osmosis selber baut? Viele Grüße, Adrian. Date: Sat, 19 May 2012 17:54:58 +0200 From: Volker Schmidt vosc...@gmail.com To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Hack-Weekend Karlsruhe und Administrative Grenzen / Hierarchien weltweit Message-ID: CALQ- OR450jLryeVYHpYr9pxzTKWUk7uHXL31Zoux6SEYEK9E=a...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 ... und wenn ihr schon ueber automatische Kontrolle der Integritaet sprechen wollt, wie waers denn mit meinem Lieblingsthema: ein relation monitor der mir jedes mal eine Nachricht schickt, wenn jemand an einer meiner Rad- (Wanderweg-, Autobus-) Routen bastelt. Leider bin ich nur Mapper und kein Hacker, und ausserdem wohne ich 700km von KA entfernt. Gruesse Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hack-Weekend Karlsruhe und Administrative Grenzen / Hierarchien weltweit
Hi! ich arbeite an der Uni Passau und wollte bei dieser Gelegenheit mal kurz einwerfen, dass an der Uni eine entsprechende BA-Arbeit läuft bzw. beginnt, bei der es genau darum geht: Es soll ein Beobachtungsdienst entstehen bei dem man sich auf verschiedene Ereignisse registrieren kann. Benachrichtigung passiert dann per RSS oder Mail. Es wäre toll, wenn du hier den Kontakt herstellen könntest. Es macht nicht viel Sinn, wenn wir zwei getrennte Projekte starten. Die Idee entstand vor allem aus dem Bedarf z.B. das Busliniennetz bzw. die Bundes-/Landstraßen im Landkreis zu beobachten damit man schnell und unkompliziert mitbekommt, wenn sich da was geändert hat (also vor allem wenn was kaputt gemacht wurde ;)). Mein Vorschlag von vorhin, beinhaltet die Benachrichtigung, ob etwas geändert bzw. unvollständig ist. Ob etwas kaputt gemacht wurde ist natürlich schon sehr anspruchsvoll. Dazu muss man wissen, ob das was vorhin war auch richtig war ;) Ich kann mir sehr gut ein System vorstellen, das aus Plugins besteht. Die Registrierung und die Benachrichtigung kann als ein Teil gesehen werden. Danach können versch. Plugins die Auswertungen übernehmen. Die User registrieren sich dann einfach auf die versch. Plugin-Events. Wenn also ein Plugin auf lückenhafte Relationen prüft und ein Alarm auslöst, werden die entsprechenden User benachrichtigt. Werde das Thema auf jeden Fall beim HACK in KA ansprechen. Vielleicht ist noch jemand daran interessiert. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API v0.6.98
(way[highway=track](s,w,n,e);node(w););out meta; ^^^ Hatte ich ursprünglich. Diese Query hat jedoch nur die Nodes geliefert, die in den Ways enthalten waren. Hmm. Hast Du die Klammern dabei? (way[highway=track](s,w,n,e);node(w););out meta; liefert Nodes und Ways way[highway=track](s,w,n,e);node(w);out meta; liefert nur Nodes. Wenn nicht, schicke mal bitte ein konkretes Beispiel. Das wäre dann ein Bug, den ich dann beheben könnte. Ah. Ok. Die Klammern ;) Die hatte ich nicht. Das für den Hinweis. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API v0.6.98
Für den Tracks Selector verwende ich folgende Abfrage: (way[highway=track](s,w,n,e);node(w)-.x;);out meta; Sie liefert genau das was ich will: alle Ways mit highway=track innerhalb der Bounding Box und die nodes dazu. Ist das die korrekte/optimale Abfrage? Ja, die Abfrage ist korrekt. Sie lässt sich noch zu (way[highway=track](s,w,n,e);node(w););out meta; oder seit dieser Version auch (way[highway=track](s,w,n,e);;);out meta; verkürzen. Inhaltlich sind alle drei Abfragen gleichwertig. (way[highway=track](s,w,n,e);node(w););out meta; ^^^ Hatte ich ursprünglich. Diese Query hat jedoch nur die Nodes geliefert, die in den Ways enthalten waren. Ich wollte jedoch eine Ausgabe von Ways+Nodes in einer Datei haben. Ist das jetzt anders? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karlsruhe HACK Weekend - Projekt Ideen
Hallo! Ich würde gerne beim nächsten HACK Weekend [1] meine Projekte Amenity Editor [2], Relation Analyzer [3] und jetzt auch den Tracks Selector [4] Interessierten OSM Entwicklern/Usern näher bringen. Ich würde euch beim Setup der Projekte helfen und zeigen wie die Projekt für eigene Ideen erweitert/modifiziert werden können. Da alle Projekte mit Java geschrieben sind, bin ich gerade dabei eine einfache Tools Sammlung aus diesen Projekten zu erstellen. Vielleicht hätte da jemand Interesse bei dem HACK Weekend mitzuwirken? Die oben genannten Projekte enthalten alle Bausteine um mit OSM Daten zu hantieren (Kommunikation mit OSM Server via OAuth, Umwandung der OSM-XML Dateien und diverse andere Konverter). Ziel wäre es eine Library zu ersten, die den ganzen Boilerplate Code abstrahiert und mit wenigen Zeilen-Code die Verarbeitung der OSM Daten erlaubt. Viele Grüße, Adrian. [1] http://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_June_2012 [2] http://ae.osmsurround.org [3] http://ra.osmsurround.org [4] http://tracks.osmsurround.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karlsruhe HACK Weekend = OSM Startup Weekend?
Hallo! Gibt es von eurer Seite Interesse an dem HACK Weekend [1] über mögliche OSM Startup Ideen zu diskutieren? Ich beschäftige mich mit OSM schon seit langer Zeit, doch jetzt nach dem Lizenzwechsel könnte man sich ja ein paar Gedanken darüber machen, wie die Arbeit der letzten Jahre auch wirtschaftlich genutzt werden kann ;) Ich habe ein paar Ideen, die ich gerne zum Austausch bringen würde. Bei einem Hackweekend lässt sich der eine oder andere Prototyp recht schnell bauen und der Sinn der Idee prüfen. Falls euch das Thema Interessiert, dann könnt ihr auf der Anmeldeseite [1] OSM Startup bei den Interests und bei Friday Pub yes angeben ;). Viele Grüße, Adrian. [1] http://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_June_2012 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API v0.6.98
Hi! von Overpass API ist die neue Version 0.6.98 erschienen. http://wiki.openstreetmap.org/wiki/Overpass_API/versions Die wichtigsten Neuerungen sind: a) eine kompaketere Syntax für Bounding-Box-Abfragen: http://overpass.osm.rambler.ru/cgi/interpreter?data=(node(50.74,7.05,50.7 5,7.06);;);out; liefert z.B. Nodes in der Bounding Box sowie alle auf diese Nodes verweisenden Ways und Relations aus. Vielen Dank. Ich finde die Overpass API recht praktisch. Habe sie zum ersten Mal beim Tracks Selector eingesetzt. Die oben beschriebene Abfrage mit dem kleiner-Operator fand ich zunächst etwas verwirrend. Ich dachte, dass sie mir alle nodes zur einer way-Abfrage liefert, aber es scheint in die andere Richtung zu gehen. Für den Tracks Selector verwende ich folgende Abfrage: (way[highway=track](s,w,n,e);node(w)-.x;);out meta; Sie liefert genau das was ich will: alle Ways mit highway=track innerhalb der Bounding Box und die nodes dazu. Ist das die korrekte/optimale Abfrage? Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
Hallo, an sich eine gute Idee, aber hast du mal über surface=* nachgedacht? Das ist weniger subjektiv bei Wegen mit grade3..5 und zusätzlich deutlich detaillierter und intuitiver. Ebenfalls in der Auswertung deutlich flexibler und daher sinnvoller verwendbar. Danke fürs Feedback. Persönlich sehe ich surface als viel zu detailliert an, so dass ich mit tracktype ein Minimum an Information haben möchte, das aber gut zu verwenden ist. Die Idee ist, die Erfassung der tracktypes zu vervollständigen, da wir bei geschätzten 90% liegen. Außerdem sehe ich den tracktype aus der Radfahrerperspektive und hier brauche ich einfach nur die Info: Rennrad-tauglich (grade1), Trekkingrad-tauglich(grade1-3) und MTB (grade1-5). Die offizielle Seite für das Projekt lautet jetzt: http://tracks.osmsurround.org Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
Am 7. Mai 2012 11:53 schrieb aighes o...@aighes.de: Hallo, gerade für das Radfahren ist meiner Meinung nach doch surface nötig. grade1 steht für befestigten oder hochverdichteten Untergrund. Das schließt nur so als Beispiel auch Kopfsteinpflaster, üble Betonplattenwege, uvm. mit ein. ich stimme mit Dir überein, dass es auf jeden Fall wünschenswert ist, auch surface Werte einzutragen. Ein grade1 ist bei mir aber grundsätzlich ein guter (ebener) Weg, nur hochverdichtet oder befestigt reicht nicht aus. Betonplattenwege sofern sie wie von Dir beschrieben übel sind, bekommen bei mir nur ein grade2, wobei das übel natürlich ziemlich subjektiv ist, Kopfsteinpflaster habe ich noch nie auf Feldwegen angetroffen, aber dafür würde ich sicher auch nur in raren Ausnahmefällen ein grade1 vergeben. Ok, ich habe noch eine checkbox hinzugefügt mit der man nach Tracks ohne surface filtern kann. (Nur unter der neuen URL: http://tracks.osmsurround.org) Seid aber nicht überrascht, dass zumindest in meiner Umgebung nicht mal (geschätzt) 10% der Tracks die surface Eigenschaft haben. Wohingegen ich mit tracktype eine realistische Chance sehe 100% zu erreichen ;) Sobald das Planet file wieder verfügbar ist, will ich nämlich ganz Deutschland auswerten und auf der Karte anzeigen. Und ja, das Design ist shit ;) Aber ich glaube kaum, dass JOSM auf dem iPad läuft. Nichtsdestotrotz habe ich den Button etwas nach links verschoben. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
Nur ein kurzes Update von mir: Der track selector kann jetzt auch die Overpass API nutzen und somit viel größere Bereiche (z.B. ein Landkreis) darstellen. Die Overpass API ist per default aktiviert und kann via Checkbox wieder deaktiviert werden. Ich glaube, wenn wir den tracktype überall eintragen, dann wird das schon sehr nützlich sein und wir können dann auch noch weitere Eigenschaften hinzufügen. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] online tool: track selector für tracks ohne tracktype
Hi! Ich habe mal ein kleines Tool entwickelt, welches ich dazu verwende die Tracks ohne das Tag tracktype ausfindig zu machen. Es ist eine Onlinekarte von OSM mit der Möglichkeit OSM Daten direkt downzuloaden. Das Tool filtert dann alle Tracks ohne tracktype heraus und zeigt sie in unterschiedlichen Farben an. Man kann danach den Track auswählen und bekommt einen Link zum JOSM Remote angezeigt. Für die Übergabe des Tracktypes kann auch ein Typ in der entsprechenden Auswahlliste ausgewählt werden, so dass JOSM diesen gleich als Vorschlag übernimmt. http://betaplace.grundid.de:8080/tracks-selector/ (Die URL ist noch nicht final. Bitte nicht verlinken) Wenn es euch interessiert dann schaut es euch an. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [talk-au] Tagging for unofficial Cycle routes in Lake Macquarie?
Greetings all, occasional mapper, first time poster. Lachlan, I live in Newcastle and cycle commute to Woodrising and have mapped a few bits and pieces around the lake. I personally would like to see your style of cycling routes on OCM but understand the slippery slope argument detailed below that would arise from different interpretations of the same route. For example when I link the Fernleigh track to Green Point the best route for me on my road bike is different to the route I take the kids on which involves a fair bit of footpath riding to avoid traffic hot spots. If you are interested I have been writing some pages for a website with links to maps on bikely, photos and route descriptions. (A project that gives a good excuse to go out cycling). Unfortunately I have not managed to make my webhosting service work, but if you send me an email (adrianplask...@hotmail.com) I will show you what I have done so far - I would appreciate comments and we could swap notes. The newcastle cycleways movement has some maps as well. Ben and Ian, perhaps you or others can help me - With regard to tagging I find that a lot of information gets lost in this process. For example I have mapped some of the minor tracks around Belmont Lagoon that allow you to extend the Fernleigh track south to Swansea without going down the highway. I know which of these paths are suitable a road bike, a mountain bike, hybrid , young kids etc, but this information is lost in my mapping with the tags dirt/gravel/width in Potlach - is there a way of making this more nuanced? I imagine every mapper knows the same things about their tracks, but the reality is (I think) that if you have not visited the area it is impossible to know if a 1m dirt path is strewn with boulders and tree roots excluding hybrids or an easy well formed path for a 6 year old. I have found some MTB tagging guidelines in the wiki but these seem more suited to formal mountain bike parks like perhaps glenrock, and I have not found how to apply them in Potlach. If I downoad one of the other editors will these appear, and will they be renderd on the standard map ? More generally to the forum thanks to all those serious mappers who have contributed so much - I have been reading the posts over the last few months from time to time and have been amazed at the amount of work and passion that have been put into this project - its great. regards adrian From: talk-au-requ...@openstreetmap.org Subject: Talk-au Digest, Vol 58, Issue 9 To: talk-au@openstreetmap.org Date: Mon, 23 Apr 2012 12:00:06 +0100 Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Tagging for unofficial Cycle routes in Lake Macquarie? (Lachlan Rogers) 2. Re: Tagging for unofficial Cycle routes in Lake Macquarie? (Ian Sergeant) 3. Re: Tagging for unofficial Cycle routes in Lake Macquarie? (Ben Kelley) -- Message: 1 Date: Sun, 22 Apr 2012 22:09:04 +1000 From: Lachlan Rogers lach...@rogers.name To: talk-au@openstreetmap.org Subject: [talk-au] Tagging for unofficial Cycle routes in Lake Macquarie? Message-ID: cadht9wb6qwtthzssjmzqfj4-noqvdwr3nmtq6wbafk97kt1...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I've recently moved back to Lake Macquarie after some years in Canberra, and I'm delighted to find that there are more cycle paths around the central coast and Lake Macquarie than I was previously aware of. Unfortunately many of them are either incomplete or disconnected from each other. I am wanting to scout out optimal on-road routes to connect cycle paths into excellent recreational routes. For instance the recently opened Fernleigh (Rail trail) Track ends in Belmont, and just a few kms away there is a great path around Green Point. I want to tag a route (probably as lcn) through the streets of Belmont so that viewers can see how best to join these rides together. To my knowledge there is no official council-endorsed cycle route. I recognise some people may have a philosophical aversion to this, because it is tagging based on usefulness rather than on what is actually on the ground. I feel, however, that we have an opportunity to scout out optimal connections and start using them for cycling now, while we lobby councils to make such routes official. I would choose a tagging scheme along the lines of network=lcn with status
