Re: [Talk-at] Gemeindegrenzen im Raum Reute an basemap.at anpassen?
Hallo, Soweit ich weiss stammen die Grenzen ursprünglich von einem import (plan.at???). Die Genauigkeit war damals recht schlecht und damals hat es auch keine guten Luftbilder gegeben. Ich habe sie angepasst wo ich es besser weiss oder später vom Luftbild korrigiert wenn sie klar über Berggipfel oder entlang Gewässern gehen sollten. Oft war das aber nur eine grobe Schätzung. Und viele andere haben wahrscheinlich Verbesserungen gemacht. Von daher ist es gut wenn wir jetzt mit basemap.at die Grenzen noch weiter korrigieren können. Falls ich Zeit habe werde ich vielleicht ein paar selbst korrigieren aber nur zu wenn du oder sonst jemand Zeit und Lust hat. -- Apo On Jan 9, 2014, at 1:41 AM, Erwin Pleyer erwin6...@gmx.net wrote: Hallo, meine Anfrage richtet sich vor allem an den Innsbrucker Stammtisch, alle Erfasser im Bereich von Tirol und solche, die mit basemap.at (bm) Erfahrung haben. Nachdem nun die Daten von bm zur Verwendung in OSM bereit stehen, habe ich folgende Frage. Im Bereich von Reutte, NW von Innsbruck, (http://www.openstreetmap.org/#map=12/47.4750/10.6717) sind zahlreiche Grenzen ohne Angabe der Source erfasst worden. Wenn man diese nun mit bm vergleicht, dann erscheinen mir die von bm doch detailierter und genauer als die vorhandenen. Eine Anfrage an den Stammtisch hat bereits ergeben, dass die Daten von bm scheinbar sehr brauchbar sind. Ich würde nun gerne die Gemeindegrenzen ohne Source, wenn sie denn nun erheblich von bm abweichen, an diese anpassen wollen, denn ich denke, es würde die Daten erheblich verbessern. Ich bitte daher um Meinungen und wenn möglich, dass der Stammtisch bei seinem Treffen am 16.01.2014 vielleicht darüber diskutieren könnte und mir dann hier Bescheid gäbe. Wäre eine tolle Sache, vielen Dank im voraus. erwin6330 aus Kufstein ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] scanned USGS Topo Layer?
as far as I have seen topo maps they are all from the 70’s or older. usually the accuracy is pretty good where things haven’t changed since. On Dec 2, 2013, at 9:37 AM, Richard Welty rwe...@averillpark.net wrote: On 12/2/13 10:01 AM, Richard Welty wrote: i guess what it comes down to is that the USGS quads are good for topo data but otherwise they're basically historic documents. and it turns out the quad that i was interested in, Bash Bish Falls on the western CT/MA border, dates from 1958. so the USGS quad layer is good for topo and historic info, but it is most assuredly not even close to current. richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Shields are up!
county route shields are not rendered in California. What is required to get them in? I have checked relations are following the same style as in New York where shields are currently rendered. California uses the standard county shield and it doesn't make sense to create a wiki page like the one for Ohio. -- Apo On Jul 29, 2013, at 10:34 AM, Phil! Gold phi...@pobox.com wrote: * Richard Welty rwe...@averillpark.net [2013-07-29 08:17 -0400]: one thing to consider in NY, though - not all counties use the yellow-on-blue pentagonal County Route signs. right now it's automagically using that style shield for all county routes. should we deal with this or let it go? I'd prefer to deal with it. I'd like the shields to match actual road signs as much as possible. If you can get me a list of what New York counties use which sign styles, I'll work on getting the rendering to match them. For what it's worth, Minh Nguyen has been working with other Ohio mappers to both get Ohio's county routes into OSM and to document the signage (and the tagging they're using) at http://wiki.osm.org/wiki/Ohio/Route_relations/Networks ; I would not at all object if people put together similar references for other states with diverse county sign styles. :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Update on highway shield rendering
direction is not part of the name and shouldn't be tagged in the name. I know especially NE2 has done that everywhere but it doesn't make sense. Signs usually say east,west,north,south not (*bound). The wiki is not consistent itself on the interstate relations page. It's important information and often signed with an additional shield. So I think best is to remove it from the name and put it in a extra tag called direction or something more specific since this is a US specific thing and direction is often different from a geographic direction on certain segments. Thought we had this tag at some time documented but right now it's not in the wilki. This makes also more sense if a routing software needs to announce correct instructions. It's a lot easier to have a clearly defined tag instead the need to parse complicated names. On Jul 10, 2013, at 1:24 PM, Phil! Gold phi...@pobox.com wrote: * Paul Johnson ba...@ursamundi.org [2013-07-10 10:28 -0500]: On Wed, Jul 10, 2013 at 2:18 AM, James Mast rickmastfa...@hotmail.comwrote: Also, do you guys think for the PA Turnpike XXX routes, that the network tag for them should be US:PA:Turnpike That's how I've been handling the Oklahoma situation: US:OK:Turnpike. Yep: http://elrond.aperiodic.net/shields/?lat=34.55064lon=-96.94071zoom=13 :) I only see two US:OK:Turnpike routes in the database at the moment, and the Cherokee Turnpike suffers from the same issue as the PA Turnpike has currently; my rendering doesn't understand name=Cherokee Turnpike (eastbound). I'm still not sure what the best way to handle that is. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Was mache ich falsch? Hilfe erbeten!
Ich habe jetzt nur ein Haus gesehen und Ich denke das ist genau richtig so. Bei einzelnen Gebäuden mit einer Adressen ist das üblich. Ein paar perfektionisten verwenden den original Adress node als einen Eckpunkt im building way um die history zu behalten. Aber das ist optional und nicht wirklich notwendig. Die history kann man schleisslich auch im changeset sehen. Und ja natürlich kannst du überall mappen und es gibt keine reservierten Gebiete und man kann keinem was wegnehmen. Wenn jemand so denkt ist er/sie bei osm völlig falsch und sollte sich besser was anderes suchen. Wenn jemand ein Problem damit hat soll er/sie das doch an konkreten Beispielen zur Diskussion bringen. Wenn allerdings jemand nur sein eigenes Ding machen will und nicht bereit ist das öffentlich auf der ML oder in einem Forum zu diskutieren ist am besten einfach ignorieren es gibt leider selten aber doch etwas komische Zeitgenossen. On Jul 4, 2013, at 6:52 AM, Erwin Pleyer erwin.ple...@gmx.net wrote: Hallo liebe talk-at Leser, ich wende mich mit einer dringenden Frage an Euch, wie man im Betreff schon lesen konnte. Was mache ich falsch? Ich mappe viel und gerne. Ich zeichne gerne Häuser, habe viele Bäche von tirol.gv.at abgepaust und übernommen usw. usw. Mappen macht mit viel Spass und ich glaube, meine Beiträge sind nicht so schlecht. Aus diesem Grunde verstehe ich es nicht, warum von anderen Mappern mit gegenüber behauptet wird, OSM Tirol wäre für mich ein EGO Projekt, nur weil ich unabsichlich im selben Gebiet wie der User Häuser gezeichnet habe und dabei von mir gezeichnete Häuser und bestehende Adressen zusammengefasst habe. Mir war nicht bewusst, dass man in manchen Bereichen eine Einladung braucht um dort mappen zu dürfen. Das Zusammentreffen in diesem Bereich geschah zufällig und absolut ohne den Gedanken, dem User etwas wegnehmen zu wollen, eben seinen Bereich. Wenn bei mir in der Gegend jemand gute und richtige Beiträge liefert, dann freue ich mich, dass wir gemeinsam die restlichen Daten erfasst haben. Es geht hier um diesen Bereich: http://www.openstreetmap.org/?lat=47.28905lon=11.67709zoom=15layers=M Kurz um, ich weiß nicht, was ich falsch gemacht habe. Angeblich wurde auf dem Stammtisch in Innsbruck weiters von einem Fall gesprochen, in dem ich einem Mapper vor den Kopf gestoßen hätte. Davon ist mir leider nichts bekannt, ich wäre über weitere Infos sehr dankbar. Wenn Gebiete zur Bearbeitung aufgeteilt wurden, woher soll man das wissen? In OSM ist das nicht ersichtlich, auch hier in talk finde ich dazu keine Einträge. In der Nachricht ist dann noch von einer Revanche die Rede und ich frage mich wirklich, was das soll! Ihr seht mich wirklich ratlos und ein wenig demotiviert, denn ich dachte echt, ich liefere gute Daten und Beiträge. Trotzdem allen einen schönen Tag erwin6330 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Grenzen
On Jun 26, 2013, at 3:15 PM, Robert Kaiser ka...@kairo.at wrote: Friedrich Volkmann schrieb: On 26.06.2013 22:56, Robert Kaiser wrote: Da, bin ich dagegen. Gemeinde und Bezirk sind Kateorien, nicht Teil des Namens und daher gehört sowas nicht in den name= tage rein. Das ist aber bei so ziemlich allen Gemeinden in AT in den Relationsnamen drin. Das ist ein Bug, der gelöst gehört. Und heißt der Bezirk Mödling wirklich nur Mödling? Ja. Er ist ein Bezirk und heißt Mödling. Es gibt auch eine Gemeinde und einen Ort mit identem Namen, aber das sind einfach 3 politische Strukturelemente mit gleichem Namen, aber verschiedener Ebene. +1 Habe auch noch nie gehört dass die Struktur offiziell zum Namen gehört. Und im Sprachgebrauch verwendet das sowieso niemand. Wer auch immer die Namen irgendeinmal geändert hat hat das vorher weder angekündigt noch diskutiert. Robert Kaiser ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Park Boundary tagging
On Mar 2, 2013, at 10:58 AM, Greg Troxel g...@ir.bbn.com wrote: I will concede that my view is contradictory to what's documented. But I think there's a fundamental semantic confusion lurking, in that boundaries are linear features, and properties of land belong as area features. welcome to osm. forget clean semantic and strict definitions. Yes it doesn't make any sense for someone with a understanding of traditional systems and technology. take the path vc. footway discussion as an example. It's still not unified and about every couple months someone starts the discussion again with no progress. almost all tags in osm are a mess but data consumers have learned to live with it. Don't change a running system ... But, I see that admin_level=8 boundaries around towns also let one define which town a particular point is in. What I am uncomfortable with is a proliferation of boundary= which is really trying to set properties of the area. If boundary=national_park is ok, why not boundary=shopping_mall, etc.? why boundary=national_park it's in use it's rendered in mapnik and other tools. why not boundary=shopping_mall. because it's not established. If you and others decide it makes sense and start to do it then maybe in a couple months the answer will be a different one. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Anyone ever talked about adding more Land Ownership data to OSM?
Full ack to to what Serge and Ian mentioned already. In addition I checked the metadata and this data is of questionable accuracy and shouldn't be added alone for this reason. Data set now is a mix of scale, tolerances, and vintage, ranging from 1994 to 2006, line work ranging from GCDB to 24K to 100K map scale/land grid source. If anyone likes to include it in Garmin maps or online maps it's really much easier to do it as a static layer. If anyone is interested to get this as a layer for Garmin maps then this can be done faster than the time it takes to upload it to osm. And whenever newer data is available it is refreshed in minutes. On Jan 7, 2013, at 8:19 PM, Serge Wroclawski emac...@gmail.com wrote: On Mon, Jan 7, 2013 at 9:34 PM, Jeff Meyer j...@gwhat.org wrote: Isn't that true of all data in the database? OSM is built on surveyors doing surveys. That is we have people who go out and walk around with GPSes, or maps, and manually survey what's on the ground. Then when a second person goes to the same area, they are validatidating the original data. Maybe the second person has more accurate data in some part, or maybe there's been a change, etc. We've shown in studies that the number of mappers increases both the data density and the data accuracy over time. But this only works with ground observable data. Land owership isn't ground observable. Sometimes a feature, such as a fence is, but the actual land owership isn't. Therefore, it's not possible for a second observer to come in and provide either validation or updates to the data. Additionally, land ownership changes frequently. Lastly, there is only one authoritative source for this data. To recap: Land ownership data is only available from the government, which is the one authoritative source of this data. It's not something that the crowdsourcing model lends itself well to. And it changes rapidly. So what Ian has suggested, and I agree with him on, is that this data is a poor candidate for inclusion into the crowdsourced OSM data. That doesn't mean it can't be used alongside it. This land ownership data (assuming it's licensed properly) can be rendered on the same map as OSM data (there are many examples of using TileMill to mix data sources in just this way) and if the data is imported into a database, there can be queries made against the two sets, so it would be possible to see the land owner for a given POI, for example. This is the best of both worlds. It keeps the OSM focusing on its strength, and makes it easy to stay current and precise on the land ownership dataset. Someone else brought up boundries, so let's discuss boundries. Boundaries in OSM, especially in the US, have been an ongoing and constant problem. Boundaries are places where people are fiddling all the time, trying to get the exact levels right. In addition, much of the US has duplicate boundaries (places represented by areas, and nodes), arguments about the definition of spaces, disagreements in the data between municipal and census data, etc. And this data changes, and we have not (even after years of working on the problem) found a good way to conflate and update. Finally, on top of that, the information Flickr has collected is telling us that our idea of neighborhoods needs to be rethought,and really does not lend itself well to the OSM model. So there too, is a potential win for OSM. We could rely on current, highly accurate public domain boundry data and use that for rendering, geolocation and other places, while keeping it out of the OSM dataset. The result of this would be: 1. More up to date maps 2. More accurate maps 3. Better geolocation (forward and reverse) 4. Reduction in errors caused by flawed data in OSM 5. Less editing wars due to differences of opinion between mappers and the authoritative data sources 6. Allowing OSM to focus on its core strength This seems like a win for everyone. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] TIGER 2012 Roads
this is the imagery url. I have just copied the 2011 setting and replaced the
year and it works for me.
tms:http://{switch:a,b,c}.tile.openstreetmap.us/tiger2012_roads/{zoom}/{x}/{y}.png
On Sep 7, 2012, at 5:58 PM, Mike N wrote:
On 9/4/2012 7:10 PM, Ian Dees wrote:
Hi all,
You may remember my TIGER 2011 rendered tile layer that's based on TIGER
shapefiles from late 2011. TIGER recently updated to include data from
2012, so I imported that data and have a new tile layer here:
http://tile.osm.osuosl.org/tiles/tiger2012_roads/preview.html#17/41.93708/-87.70124
I feel stupid, but I tried that in JOSM as an image lary, as well as some
variations, but couldn't get it to work. Is there any way to make it work as
JOSM imagery?
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Deleted ways
Hi, looked at all changesets and it's a new user. all changes are destructive all edits are deletion of ways or deletion of points in ways and I decided to revert 2 changesets. the remaining changesets are already obsoleted by other edits. On Jun 20, 2012, at 5:19 PM, Aleš Trtnik wrote: Hi, I noticed, that user lautschi11 deleted few ways, so some relations are incomplete. I tried to undelete those ways, but I wasn't successful. I don't realy know how. All his edits are a bit questionable. Especially changeset 11746092 which resulted in incomplete relations http://www.openstreetmap.org/browse/relation/357370, http://www.openstreetmap.org/browse/relation/356961 and http://www.openstreetmap.org/browse/relation/1758279. Can someone try to look into this, and undo his deletes. Regards, Lesko987, Slovenia ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Menlo Park Admin Boundary
this one deleted the MV,SV border. not much damage otherwise http://www.openstreetmap.org/browse/changeset/11044834 The challenge with the other changeset is the size. analyzing the history is so hard. Reverting a whole changeset is very difficult with subsequent edits of others. There will be so many conflicts in that process that going forward things is often easier. especially some of these borders had been imported over each other and there is still duplicates and misaligned borders. I am not aware of a high quality set of city borders. The tiger borders are of very low quality and where possible I have aligned to the county borders. On Jun 8, 2012, at 4:13 PM, the Old Topo Depot wrote: Thanks, Apollinaris, for the additional updates. BTW, what are the changeset IDs that touched the other admin ways, please ? Further examination of changeset 11339421 reveals deletion of Sharon Heights Golf Course, some surrounding ways, and other point features in the immediate vicinity, including exit numbers on I-280, emergency call boxes, as well as other features. See http://www.openstreetmap.org/?lat=37.4251091480255lon=-122.214467525482zoom=16 It may be prudent to revert the entire changeset, given the number of deletions contained, and the fact that this changeset is the only committed by bxbreen (http://www.openstreetmap.org/user/bxbreen). Unfortunately, at least the Sand Hill/I-280 interchange has been subsequently edited by others. Thoughts on how best to proceed are appreciated. Best, On Fri, Jun 8, 2012 at 9:53 AM, Apollinaris Schoell ascho...@gmail.com wrote: there is more damage to the borders in the area. I have removed some duplicates for Menlo PArk now and fixed PA,EPA,MV,SV too. looks like another pretty new user deleted even more boundaries. On Jun 7, 2012, at 9:16 PM, the Old Topo Depot wrote: It appears that changeset 11339421 deleted way id 108849539, which was a part of the Menlo Park admin boundary. As the changeset is rather large (2,304 nodes; 160 ways) a full revert seems undesirable. What might be the best way to recover the deleted way and restore the associated relation without attempting a full revert ? Thanks in advance, John Novak ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- John Novak ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Menlo Park Admin Boundary
there is more damage to the borders in the area. I have removed some duplicates for Menlo PArk now and fixed PA,EPA,MV,SV too. looks like another pretty new user deleted even more boundaries. On Jun 7, 2012, at 9:16 PM, the Old Topo Depot wrote: It appears that changeset 11339421 deleted way id 108849539, which was a part of the Menlo Park admin boundary. As the changeset is rather large (2,304 nodes; 160 ways) a full revert seems undesirable. What might be the best way to recover the deleted way and restore the associated relation without attempting a full revert ? Thanks in advance, John Novak ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] OT: Hausnummern
On Mar 9, 2012, at 11:11 AM, Andreas Labres wrote: On 09.03.12 17:38, Boris Cornet wrote: Bei uns (Tirol) am Land sind Hausnamen durchaus üblich, Hast ein Beispiel? IMO ist ein Hausname unter addr:housename nur sinnvoll/angebracht, wenn der tatsächlich (unverzichtbarer) Adressbestandteil ist. In AT wüßte ich das nicht, weil's da immer Hausnummern gibt. wer definiert dass das unverzichtbar entscheidend ist? Hausnamen existieren schon viel länger als Adressen und lokal kennt die jeder. Der Briefträger wird das sicher zustellen auch wenn keine Nummer am Brief steht. Und name ist wirklich nicht der richtige tag. Einen neuen tag zu erfinden macht wohl auch keinen Sinn nur weil die Bedeutung leicht von anderen Ländern abweicht. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Adressen und Relationen
On Mar 6, 2012, at 11:35 AM, Friedrich Volkmann wrote: Ich habe ein grundsätzliches Problem mit Redundanzen. Eine Information an 1 Stelle kann leichter korrekt und aktuell gehalten werden als an tausend Stellen. Irgendwer vertippt sich, und dann ist schon ein Fehler drin. Wenn jemand mit Autovervollständigung arbeitet, breitet sich der Fehler sogar aus. Ohne Redundanz. Ein Fehler und es ist an tausend Stellen falsch. Das ist eine rein philosophische Frage was bei crowd sourcing besser ist. Und wenn die Post eine PLZ in einem bestimmten Gebiet ändert, muss man alle Vorkommen in dem Gebiet ändern. Dann braucht man erst recht ein Grenzpolygon. Also warum nicht gleich. Soviel ich weiß, gibts in DE die PLZ-Multipolygone schon. Nur in AT sind wir hinten nach. Theoretisch super aber in der Praxis sind multipolygone sowas von fragil. War ja auch ein Fan aber in der Realität wird der Krampf nur von wenigen Editoren unterstützt und nur von einer Minderheit der Mapper wirklich verstanden. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] [Talk-us] Check my junctions - looking for someone to review my plates of spaghetti
+1 it's nowhere close to a standard to split lanes. It is just a plate of spaghetti. hard to edit and maintain for no good reason. If it where anywhere where I care I'd just revert that. On Jan 23, 2012, at 8:20 PM, Nathan Edgars II wrote: On 1/23/2012 9:52 PM, dies38...@mypacks.net wrote: Over the past couple of months, I have armchair-mapped several highway junctions in the United States which are commonly complex in that they involve multiple turn restrictions, street name changes and pedestrian crossing placements. I would like to have some critique from someone experienced in mapping such junctions so that I ensure I am following current best practice and am not just creating a bunch of plates of unpalatable spaghetti. Two recent junctions are found in the following permalink views * http://www.openstreetmap.org/?lat=40.095879lon=-75.296179zoom=18layers=M * http://www.openstreetmap.org/?lat=39.128273lon=-77.237731zoom=18layers=M Yuck. A separate way should not be used for a turn lane (unless that lane is separated by barriers or maybe a wide striped-off area). Corollary: a separated right-turn lane begins and ends approximately where the traffic island begins and ends, not where the separate lane begins and ends. Turn restrictions are not for identifying which lane goes where. They are for restrictions on turning (e.g. if no left turn is allowed, you use a no_left_turn restriction). Thus neither example needs any restrictions, since you can turn in any direction from any approach. (Some mappers like to use what are, frankly, completely redundant restrictions that force you to do what any router will have you do anyway, such as no right turn at the intersection if there's an island-separated right turn lane.) The second one is a simple crossing of two divided roads, found all over the place (e.g. http://www.openstreetmap.org/?lat=28.38582lon=-81.506134zoom=18layers=M - note if you check against the aerial that the west-to-south right turn has recently received an island). Of course the above is just my opinion, strongly influenced by what I have seen as standard practice all over the country. ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] [OSM-talk] Check my junctions - looking for someone to review my plates of spaghetti
+1 it's nowhere close to a standard to split lanes. It is just a plate of spaghetti. hard to edit and maintain for no good reason. If it where anywhere where I care I'd just revert that. On Jan 23, 2012, at 8:20 PM, Nathan Edgars II wrote: On 1/23/2012 9:52 PM, dies38...@mypacks.net wrote: Over the past couple of months, I have armchair-mapped several highway junctions in the United States which are commonly complex in that they involve multiple turn restrictions, street name changes and pedestrian crossing placements. I would like to have some critique from someone experienced in mapping such junctions so that I ensure I am following current best practice and am not just creating a bunch of plates of unpalatable spaghetti. Two recent junctions are found in the following permalink views * http://www.openstreetmap.org/?lat=40.095879lon=-75.296179zoom=18layers=M * http://www.openstreetmap.org/?lat=39.128273lon=-77.237731zoom=18layers=M Yuck. A separate way should not be used for a turn lane (unless that lane is separated by barriers or maybe a wide striped-off area). Corollary: a separated right-turn lane begins and ends approximately where the traffic island begins and ends, not where the separate lane begins and ends. Turn restrictions are not for identifying which lane goes where. They are for restrictions on turning (e.g. if no left turn is allowed, you use a no_left_turn restriction). Thus neither example needs any restrictions, since you can turn in any direction from any approach. (Some mappers like to use what are, frankly, completely redundant restrictions that force you to do what any router will have you do anyway, such as no right turn at the intersection if there's an island-separated right turn lane.) The second one is a simple crossing of two divided roads, found all over the place (e.g. http://www.openstreetmap.org/?lat=28.38582lon=-81.506134zoom=18layers=M - note if you check against the aerial that the west-to-south right turn has recently received an island). Of course the above is just my opinion, strongly influenced by what I have seen as standard practice all over the country. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Getting ready for the license change
If you really want to understand this you will need to ask a lawyer. or start a discussen on talk-legal to me it looks like some political game and splitting hairs about some of the CT details. Considering balrog-kun has a new account where CT is accepted and this declaration then all the data can be adopted by any mapper and declared odbl clean. all the bot edits are already declared odbl clean at http://wiki.openstreetmap.org/wiki/Quick_History_Service#Changeset_Overrides and my interpretation is that the whole user account can be adopted On Jan 13, 2012, at 2:07 PM, Mike N wrote: On 1/13/2012 4:50 PM, Paul Johnson wrote: Speaking of, has anyone talked to balrog-kun yet? I know he was at one point insanely prolific and I often stumble across his data, he's currently a decliner. I don't have a clue what the below statement means, since he hasn't said he'll make his edits Public Domain. http://www.openstreetmap.org/user/balrog-kun All of my contributions* made through this account are ODbL-compatible. You are free to use my contributions under the terms of either CC-By-SA or ODbL* licenses at your preference, and you are free to sublicense my contributions under ODbL 1.0 without attributing me other than as OpenStreetMap contributors. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Medians and reverts
On Dec 22, 2011, at 10:53 AM, Paul Johnson wrote: On Wed, Dec 21, 2011 at 04:11:09PM -0600, John F. Eldredge wrote: Nathan Edgars II nerou...@gmail.com wrote: On 12/21/2011 12:45 PM, Paul Johnson wrote: In California, carpool lanes are seperated by a painted median. This is what's in dispute. Is the following a median or simply a lane separator? http://www.scvresources.com/highways/118_hov_lane.jpg Are the HOV restrictions in effect at all times, or only for part of the day? The HOV restrictions on inbound highways in Nashville, TN are only in effect for certain morning hours on weekdays (inbound rush hour), and those on outbound highways are only in effect for certain late-afternoon hours on weekdays (evening rush hour). The rest of the time, the HOV lanes are treated as normal lanes. If the HOV lane restrictions are not 24/7, I would class those as lane separators, not medians. Also, if a vehicle with enough passengers is allowed to move into/out of the HOV lanes at any point, I would not classify the markings as a median, but only as a lane separator. In California, most are 24/7. When they're not, they're either closed to all traffic and treated as dead space, or PSV-only outside HOV hours. All traffic is prohibited from making lane changes in areas where the white-orange-orange lines are present, with the general access lanes functionally being the right shoulder for HOV traffic, and the HOV area treated as the left shoulder for general access traffic. Every 1-3 miles where lane changes are permitted, lane changes in and out of the HOV area is permitted for traffic allowed in that lane, no other locations. These restrictions are strictly enforced, as the difference in speed between the HOV lane and general access is frequently in excess of 60 MPH during peak traffic periods in sections where the HOV lane is isolated. Not at all. California is large and isn't consistent across different counties. I know only a single place where it's like that in northern California. And this is a new and special testing area it's not only a normal HOV lane it's a pay per use at rush hours and free to use otherwise. Cost varies based on traffic. Not exactly a HOV lane where use is allowed for cars with a minimum of 2 or 3 passengers or fuel efficient cars. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-legal-talk] feedback requested
+1 for both items On Dec 20, 2011, at 12:27 PM, Richard Weait wrote: Dear All, LWG would like feedback on a couple of items relating to cleaning tainted data as we all prepare for the data base transition. Draft minutes are here. https://docs.google.com/document/pub?id=1ZIQSl0xXpUFbqTeknz61BYgfCINDTzlAWomOiGxhgG8 Of particular interest are: - can node positions be cleaned by moving to a new position? - is a mapper declaration of odbl=clean interesting and helpful in reconciling the data base? As seen here: We discussed the moving of nodes and whether they could be clean: We have seen a concern expressed where an node is moved by an agreed mapper and that is the last position, should it not be deemed clean (even if created dirty)? Conclusion: Yes, we are OK with that, the assumption being that the move is made in good faith with a reference source, (survey, Bing imagery, …). We consider that the creation of an object and its id to be a system action rather than individual creative contribution. Tags on the same node must be considered separately. The LWG would like to adopt this as policy and would be grateful for community feedback. Frederik has recently proposed a new tag, odbl=clean, to be set by mappers who will vouch for the odbl compliance of any object. The LWG would like to adopt this as policy and would be grateful for community feedback. We look forward to your thoughtful, insightful feedback. Best regards and Happy Mapping, Richard Weait on behalf of LWG ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] instead of replacing data can I just revert to the last known clean version?
On Dec 16, 2011, at 12:03 AM, Frederik Ramm wrote: I think it would be good to have a tag that mappers can use to say this object is clean, I have personally checked the history and/or reverted it to a relicensable state, any contributions by non-agreeing users are not present in the current version any longer. +1 replacing tainted data is a pain with current tools. there must be a some support to define an object (not just a changeset) as clean. This is the only chance to keep object history. This should apply to all nodes if this tag is set on a way. At least for nodes without additional tags this should be a reasonable assumption. No one will really draw or verify way nodes independent from creating/verifying a way. tainted nodes with additional tags should retain only the position. This is really important to keep connectivity of the road network intact. if the node tags are tainted we can not keep them. For relations this seems be to tricky and I would not go that far to push a odbl clean flag to it's members Then, if you revert an object to an earlier version, you'd just add that tag to express then even though the object history does contain contributions by non-agreers, it can remain. I am experimenting with using the tag odbl=clean for this, and will build support for that into the OSMI relicensing view. But the matter still needs to be discussed properly, and with OSM Inspector not being an official site in any way, it is not for me to say whether such a tag would be honoured when the day comes. I assume the LWG will follow your implementation as Simon's later post in this thread indicated. The final switch is on DB level so we should do some dry run and compare with yours well before April 1st Bye Frederik ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-at] das 'new barrier types' proposal
On 2 Sep 2011, at 6:10 , Boris Cornet wrote: Es scheint schon wieder ein Schreikrampf fällig zu sein ;-) Langsam geht mir dieses hyperrealistische 'Malen nach Zahlen' ganz schön auf die Nerven. Wenn man jedes Detail haben will, dann soll man ein Luftbild anschauen. OSM soll das bleiben, was es immer war: einen geografische *Datenbank*, die darauf ausgerichtet ist, Zusammenhänge zu erfassen. Die Karte ist nur einen visuelles Folgeprodukt, erstellt von einem Renderer! Offen gesagt ist mir die Karte gar nicht so wichtig, das wahre Potential von OSM liegt ganz woanders, u.a. im Routing. Erstmals nähern wir uns der Möglichkeit, Blinden- und Rollstuhlrouting zu ermöglichen. Das geht aber nur mit einem konsistenten Datenbankmodell, und perfekte Visualisierbarkeit läuft eben der Erfordernis zur Generalisierung zuwider. Ausserdem: eine gute Karte ist *nicht* das exakte Abbild der komplexen Wirklichkeit, sondern stellt die Wirklichkeit bewusst vereinfacht dar, um eben die Zusammenhänge zu verdeutlichen. +1, solltest du auf talk-de posten ;-) Dann gehts dort wieder Monate lange Diskussionen. -- Bis bald, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Removing non-CT data method?
Why? it's replaced by a building polygon. so it's improvement of data and license status. On Thu, Sep 1, 2011 at 3:06 PM, Nathan Edgars II nerou...@gmail.com wrote: On 9/1/2011 5:39 PM, Mike N wrote: http://www.openstreetmap.org/**browse/node/469532416/historyhttp://www.openstreetmap.org/browse/node/469532416/history The last 2 edit authors have accepted the CTs, but the feature is still deleted? Looks like vandalism by rw__. __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing non-CT data method?
You have been too fast in adding them and fix the data. Certainly agree that a building alone has not much value. drawing nice looking maps is not much value compared to a verified POI On Thu, Sep 1, 2011 at 5:34 PM, Mike N nice...@att.net wrote: On 9/1/2011 6:14 PM, Apollinaris Schoell wrote: Why? it's replaced by a building polygon. so it's improvement of data and license status. The building polygon has no tags except building=yes. An anonymous building has less value to OSM than a searchable POI in my opinion. __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Caltrans exit numbers
Santa Clara county was sued successfully, but not on a federal level. State of California has the same PD rules and this can be used only for California state and county data. Don't have the link available right now but it can be found in the archives of talk-us But still you may need to check data offered at CASIL website. It is a mix of state and data provided by private companies. One example is Greeninfo data which is not PD. On Mon, Mar 28, 2011 at 9:15 AM, Alan Mintz alan_mintz+...@earthlink.netwrote: At 2011-03-23 04:22, Dale Puch wrote: A quick note, do not confuse public records as always meaning public domain. Some states may not have laws specifically preventing agencies from claiming copyright, not apply to all levels of government, or have exceptions to which works. IE. I think it was Michigan that specifically copyrights it's gis data. Some offical state clearinghouses may claim copyright on what should be public domain from the various agencies. http://wiki.openstreetmap.org/wiki/Potential_Datasources#U.S. is the best compilation of sources and notes about them I know of for our use. I would suggest to update it with any information you come up with. Hasn't there been recent case law, though, that enforces a federal principle (?) that any data produced by a government agency must be public domain (excepting obvious things like national security)? Wasn't Santa Clara County, California sued successfully? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Österreich-Statistik zur Re-Lizenzieru ng
On 22 Dec 2010, at 9:23 , martin ringer wrote: Danke für die Links bzw für die Liste. Ich finde, dass die Zustimmung in Österreich noch besser sein könnte. Werden User, die viel gemappt haben und noch nicht zugestimmt haben, von jemanden aus der Community angeschrieben? Ein Verlust der Daten wäre nicht so toll. Bloss nicht. Wenn viele beginnen dies User anzuschreiben wird das eine Spam ohne Ende fuer die. Und sie nicht gerade motivieren. Wartet doch erst ab bis die OSM offiziell alle anschreibt. Dann ist immer noch mehr als genug Zeit. Klar wenn man jemand kennt und schon frueher in Kontakt war ist das was anderes und dann spricht nichts dagegen. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Address Node Import for San Francisco
On Thu, Dec 9, 2010 at 4:38 PM, Gregory Arenius greg...@arenius.com wrote: The wiki states that this is how address nodes are done. They can be attached to other objects of course but they can also be independent. Like I stated earlier I did check how they are actually being done elsewhere and the ones I've seen entered are done in this manner. Also, why do you think of them as noise? They're useful for geocoding and door to door routing. The routing in particular is something people clamor for when its lacking. individual address nodes are common and there is nothing wrong adding them As for attaching them to buildings that doesn't particularly work well in many cases especially in San Francisco. For instance a building might have a number of addresses in it. A large building taking up a whole block could have addresses on multiple streets. Also, we don't have building outlines for most of SF and that shouldn't stop us from having useful routing. setting address to a building is good if there are buildings. but in this case it makes absolute sense to have individual nodes. in case of multiple addresses on one building the address nodes can be used as a node in the building outline to mark the individual entrances on large buildings. but this is really optional. Also, there are a large number of places where there are multiple nodes in one location if there is more than one address at that location. One example would be a house broken into five apartments. Sometimes they keep one address and use apartment numbers and sometimes each apartment gets its own house number. In the latter cases there will be five nodes with different addr:housenumber fields but identical addr:street and lat/long coordinates. Should I keep the individual nodes or should I combine them? don't combine them if they have different house number. reality is there are different address so we should map all of them even if the location is the same. I hear this every time imports come up. I got it. Its hard. Thats why I'm soliciting feedback and willing to take my time and am really trying to do it correctly. I'm not willing to just give up because there have been problems with imports in the past. I would say this is one of the easy imports, there is not too much harm it can create. only problem is to merge it with existing data and make a decision which one is better. Since this data is probably authoritative it might be ok to replace most of the less accurate data already in OSM. For this reason I would drop any of the nodes in case of a conflict but rename the tags to something else like sf_addrimport_addr:* a survey on the road can check them later and compare with the existing addr nodes and decide which one to keep and rename the import tags to the real tags ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Google fumbles again in latin america
On 5 Nov 2010, at 8:09 , Serge Wroclawski wrote: On Fri, Nov 5, 2010 at 11:03 AM, Toby Murray toby.mur...@gmail.com wrote: On Fri, Nov 5, 2010 at 9:22 AM, Serge Wroclawski emac...@gmail.com wrote: AFAIK no one has ever advocated removing the TIGER tags other than tiger_reviewed = no. Actually... http://lists.openstreetmap.org/pipermail/talk-us/2010-July/003761.html Epic trolls don't count. he is not a troll and has never been. who are you to call someone a troll because you don't agree? And I'd consider that vandalism. I consider it improving osm by a human mapper according the spirit of the project instead a container full of imports with not much value. If a human surveys on ground or based on personal knowledge and image tracing it has 100 times more value than any imported data - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Google fumbles again in latin america
hmm, sorry got the wrong name here, reading from pipermail Alan's name was highlighted and Anthony's wasn't :( have to agree on the trolling, and it jsut got confirmed Also, in the case of image tracing, one is recommended to mention a source= tag. Not everyone does that all the time (I don't do it often, when I should), but the idea there is the same- to illustrate the data lineage. with most data in PD and Yahoo and many other free images it doesn't matter so much in US. source is more important where copyright is a minefield - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] [OSM-dev] Super-relations or not
On 29 Oct 2010, at 9:05 , Peter Budny wrote: P.P.S. Why do I see so many route relations where a way has been added more than once, sometimes up to 5 times, with the same role? What is that supposed to mean? typically an error. only use case where it makes sense is a bus route which sometimes uses some segments of a road multiple times -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Peaks
I recommend USGS maps. GNIS is based on some automatic processing. It's much lower on steep peaks. I found even more difference than your example. On 23 Oct 2010, at 5:52 , Nakor wrote: Hello, I was looking at peaks in Glacier National Park. There are quite a few that have been imported from GNIS. NPS has also a database of such peaks. My issue is that the databases are not consistent. If I take for instance Mt Cleveland: GNIS: 48.925 , -113.8480556 3175m (10417ft) NPS: 48.9227541, -113.8472346 3190m (10466ft) That's a little bit more than 1/8 mile off horizontal and 50 ft off vertical. Is there any other source of information to try and figure out what is the correct data? Thanks, N. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Request for community mediation
On Thu, Oct 21, 2010 at 3:54 PM, Frederik Ramm frede...@remote.org wrote: I suggest that you ignore Paul's tagging as long as he uses it in his local area. If you can't manage to do that, maybe try a Yoga class. Cool down. Paul's tagging sure is quirky but who knows, sometimes these quirky things lead to something cool built on top of them. If not, then they will die out by themselves. No need for you to police Paul's harmless edits *even* *if* *they* *should* *be* *wrong*. Do you know the saying the wiser head gives in? +1 there is so much to do in US. absolute no need to fight anyones edit as long as they don't break things ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Garmin maps for India? Contours?
On Mon, Oct 18, 2010 at 5:17 AM, Charlie Ferrero char...@cferrero.netwrote: Contours are a pain. If you've really left this to the last minute then you're not going to want to get up the learning curve for creating your own for Garmin devices. I have a little script which can do it from download to mkgmap. requires a bunch of utilities installed like gdal, proj4, shp2osm, perl ... once this is done it is only a question of compute time. for northern india srtm is probably bad quality and viewfinderpanorama will be much better with all the voids filled in. don't have access to my machine currently so can't help for a short term map creation. eventually can get to access the scripts later today -- Charlie ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Versatz yahoo / geoimage
On 12 Oct 2010, at 23:51 , Norbert Wenzel wrote: On 10/13/2010 07:41 AM, Georg Ringer wrote: Es gibt scheinbar einen Versatz geoimage zu Yahoo, der bei kurzen Tests bis zu 30m beträgt. Kann mir wer sagen wo hier der Fehler liegt bzw kann man sich auf einer der 2 Luftbilder verlassen wenn man keinen GPS-Track selbst zur Hand hat? Im Zweifel würd ich Yahoo ignorieren. Nein in dem Fall nicht. Das Josm plugin funktioniert nicht 100% und hat definitiv eine Verschiebung. In Josm kann man WMS einfach verschieben und an tracks anpassen. lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Versatz yahoo / geoimage
On 13 Oct 2010, at 8:57 , Norbert Wenzel wrote: On 13.10.2010 17:08, Apollinaris Schoell wrote: On 12 Oct 2010, at 23:51 , Norbert Wenzel wrote: On 10/13/2010 07:41 AM, Georg Ringer wrote: Es gibt scheinbar einen Versatz geoimage zu Yahoo, der bei kurzen Tests bis zu 30m beträgt. Kann mir wer sagen wo hier der Fehler liegt bzw kann man sich auf einer der 2 Luftbilder verlassen wenn man keinen GPS-Track selbst zur Hand hat? Im Zweifel würd ich Yahoo ignorieren. Nein in dem Fall nicht. Das Josm plugin funktioniert nicht 100% und hat definitiv eine Verschiebung. In Josm kann man WMS einfach verschieben und an tracks anpassen. Guter Einwand. Wenn man nicht gerade Merkaartor korrekt einsetzt, wie es hier von Boris beschrieben wurde, bzw. das JOSM Plugin von Fichtennadel verwendet sollte man aufpassen. Aber wenn man mal davon ausgeht, dass alles korrekt eingebunden ist, würd ich auf die Yahoo Bilder verzichten im Zweifel. ja klar, uebrigens google verwendet auch die Bilder von Geoimage oder eine variante davon. auf http://sautter.com/map/ kann man ganz gut vergleichen wie alles zusammenpasst. lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-legal-talk] Fwd: Re: Two questions to LWG
On 2 Sep 2010, at 4:52 , TimSC wrote: To LWG, cc legal talk You have not provided an acknowledgement of my recent emails of 11th Aug, 18th Aug (beyond Grant's message of 27th July). Obviously, you are busy but I also don't have time to keep going through my emails and your minutes to see if any discussion has taken place. I first raised the produced works/CC0/PD compatibility issue with you back on 25th May. Who are you to demand a response from people working in their spare time? You are not even willing to spend the time to read minutes and emails but expect individual response. If every mapper of the 10-20k active mappers expects this then tell me how the LWG or OSMF can do this? hire 500 lawyers to repeatedly answer the same question? What I have learned only a lawyer or a court desicion can give final answers. Whatever LWG says is less than an advise and absolutely not binding. and just to be clear, I am not an osmf member or in any way involved in the license change. Just tired of endless discussions and disrespect of the work these guys are doing. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] Can US OSM help with license upgrade? (was: Re: License Upgrade - Stage Two Begins)
On Mon, Aug 16, 2010 at 1:26 PM, Dale Puch dale.p...@gmail.com wrote: A real problem is that the data itself is not properly tagged, or does not explicitly state what if any restrictions are placed on it. When it is not perfectly clear is when non-lawyers like us are putting themselves and OSM in possible trouble. if it's not tagged we must assume it is under copyright and not PD A few examples: The web site has copyright notices on it, but the shape file data for access is blank but asks for attribution... An e-mail response regarding this is that we can use it with attribution. What satisfies the attribution, and is that e-mail valid permission for the data use? I think email has been used in many cases in court, so let's assume good faith if there is an email. Even if you have a written letter you will not do research to prove that the signature is real. that the letter is from the company and the signer is allowed to sign such a permit Some place charge a fee to get the data, but is it then free to then copy and reuse? as long as the fee is cost of distribution then data itself may still be PD Official state clearinghouses (usually a university) will sometimes edit the shape files to include copyright, even though the source data was specifically not. Free to get and use for personal use is not equal to public domain. Exactly, this is no longer PD and you need the original source. But it will be impossible for anyone to prove that you took their non free data. they can add easter eggs so better to stay away from using such data ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Over-digitized imports?
On 19 Aug 2010, at 20:35 , Nathan Edgars II wrote: On Thu, Aug 19, 2010 at 11:24 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: Should imports make an effort to un-smooth such data to some extent, for the benefit of editing and rendering performance, storage, etc? hm, yes and no. currently we render only to zoom level 17, but it might change in future. And we don't map for a specific renderer. As long as the point density is reasonable why not keep it. http://wiki.openstreetmap.org/wiki/Convert_shp_to_osm_using_grass_and_gpsbabel recommends doing this. it describes a method but I can't see any recommendation here. btw JOSM can do the same. default is a bit aggressive but can be changed in the enhanced settings ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Can US OSM help with license upgrade? (was: Re: License Upgrade - Stage Two Begins)
On Thu, Aug 12, 2010 at 7:23 AM, Nakor nakor@gmail.com wrote: Most of my contributions even though based on my GPS tracks are derived work of some US governement data (USGS and NAIP imageries) and in a lesser extent Ohio through OSIP. I also imported some NHS, NPS and TIGER datasets. I truly do not want all that work to be lost and I trust the LWG when they say that ODBL is going to be more protective than CC-BY-SA for the project. My only issue is the first paragraph of the Contributor Terms. I do not have **explicit** permission from the various US government entities and do not feel comfortable accepting those terms. US government data is public domain. you can do whatever you like to do with it. All big ones from Garmin, Google ... you name it use this data. there is absolute no need to get explicit permission for individuals. It is the law and what can be more explicit than that. As an example county of Santa Clara even lost the law suit a couple of years ago when they tried to protect and sell their data for more than redistribution costs. One of the mission of the US OSM could be to get explicit permission from those federal/state/local government entities that we derived data from. Thanks in advance, N. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Can US OSM help with license upgrade? (was: Re: License Upgrade - Stage Two Begins)
On Thu, Aug 12, 2010 at 8:20 AM, Al Haraka alhar...@gmail.com wrote: On Thu, Aug 12, 2010 at 11:06 AM, Apollinaris Schoell ascho...@gmail.com wrote: US government data is public domain. you can do whatever you like to do with it. All big ones from Garmin, Google ... you name it use this data. there is absolute no need to get explicit permission for individuals. It is the law and what can be more explicit than that. As an example county of Santa Clara even lost the law suit a couple of years ago when they tried to protect and sell their data for more than redistribution costs. I do not know if you are a lawyer, or even one with sitting on the bar in any jurisdiction in the United States. That being said, neither am I. The Santa Clara case, the similar one in Schenectady, NY, and dozens of others are good examples of what you mean. But still, blanket generalizations from people without legal credentials, *me* included, will not prevent us from getting sued or into legal trouble or building something that holds water so we can prevent others from screwing us/abusing all the hard work we do. Also, notice the few attorneys involved with OSM (SteveC mentioned them) have the scruples to not discuss it with lots of us, as it will not help and people construing their emails on these lists as bona fide legal advice gets them in trouble. Hence, they have been very silent the entire time despite people demanding answers on licensing as of late. That is not an accident. This is why I asked about their capacity as attorneys earlier. I do not mean to be rude or start a flame, but what legal resources are necessary whether or not we like to think all USG data is PD, and we can do whatever we want with it. I am not even close to be a lawyer but this is has been discussed and proved in court many times. this maybe different for some states and is different for data provided by companies or organizations even when the government funded them. -- Alexander J. Stein Cell: (201) 412-9479 Email: alhar...@gmail.com Skype: alexander.j.stein AIM: elduderino6886 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Enough is enough: disinfecting OSM from poisonous people
What are your ideas? How should we block people? For how long? What process should it be? What are the best practices from other projects you're involved in? agree 99% with all of this posting and the only part is this. osm has open in the name and there is no need to block people. Everyone capable of subscribing knows also how to filter certain names. the real question is how to move forward as fast as possible and get the whole license discussion out of our mind. As several asked already let's open the vote for old accounts to dual license and get a strong vote for a license. as soon as a decision is final most of the poisonous people will leave. I think we can easily accept loosing a handful of poisonous people because all others will spend less time dealing with them and be more productive. sure some will continue but then it's definitely time to think about blocking them. thanks for writing this post. I am getting tired too of these endless discussions! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
On 5 Aug 2010, at 14:43 , Alan Mintz wrote: At 2010-08-05 11:52, Ian Dees wrote: ... It isn't any different. I had made the (bad) decision at the time to import over any existing data because in the several hundred places I spot-checked, NHD was vastly superior in resolution (and probably quality). By import over, do you mean to add duplicates, replace the existing features, or merge the info from the two manually? As I manually survey various features (POIs, some hydro, etc.), I usually try to merge in the data from existing imports so as to maintain the link (e.g. gnis:feature_id) back to the original database, in case we want to exchange updates with them again. this is impossible due to the license terms, One thing that occurs to me that may be a problem is that I occasionally have to delete a feature that is no longer present (e.g. http://www.openstreetmap.org/browse/node/358808220). If we were to feed an update back to GNIS or get one from them, this situation would have to be taken into account. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
On 6 Aug 2010, at 1:45 , Nathan Edgars II wrote: On Fri, Aug 6, 2010 at 3:50 AM, Apollinaris Schoell ascho...@gmail.com wrote: On 5 Aug 2010, at 14:43 , Alan Mintz wrote: As I manually survey various features (POIs, some hydro, etc.), I usually try to merge in the data from existing imports so as to maintain the link (e.g. gnis:feature_id) back to the original database, in case we want to exchange updates with them again. this is impossible due to the license terms, There are no (valid) license terms applicable to something of the form OSM deleted feature 687645; check independently whether it exists and delete it from GNIS if not. sure not in this form, this form requires so much work on GNIS side that it will probably never happen. the deletion of the node can happen for so many reasons that without documentation it has no value. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
It's the API not JOSM. You have to be patient. On 5 Aug 2010, at 24:40 , Kevin Atkinson wrote: This is in progress, and taking forever (I about 10,000 ways in all). Apparently uploading large changesets with JOSM takes a long time. Not sure if it's JOSM or the server. Worse, I started to upload some changes (using 1000 size chunks as JOSM couldn't handle it all at once), but it took forever and didn't look like it was making progress so I canceled it. Well apparently the server got the changes and posted them so when I tried again I got a conflict. ... and than after trying various things which I won't go into I got things going again, this time using 100 size chunks so at least I know its making progress. Moral of the story, when uploading a large changeset with JOSM use small chunks (like 100) or be very very patient. BTW: I also looked into using an upload script, but the only one I could find that would do what I want with the new API (0.6) requires python 3 which I don't have installed (there is a python 2 version, but that failed with a syntax error). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Tue, Aug 3, 2010 at 11:04 PM, Kevin Atkinson ke...@atkinson.dhs.orgwrote: On Tue, 3 Aug 2010, Apollinaris Schoell wrote: On 3 Aug 2010, at 22:32 , Kevin Atkinson wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. most of the times I see it name=Frontage Road ref=US 29 this will be rendered in similar way as on other maps. Name is on the street and US, I, is on a shield. Doesn't make sense to duplicate the ref on the name. Since when does a frontage road get a Highway shield? got this wrong and meant Frontage road is a name, but now need to correct altogether. but what is meant here has most likely no name at all. frontage road is a then a type of highway not a name. and US 29 in any form is not really a name either. again all other maps will not render names unless there really is a defined name. normally ramp, access road, frontage road are mapped as highway=*link without name And in any case you are saying that the frontage road is part of US 29? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On 3 Aug 2010, at 22:32 , Kevin Atkinson wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. most of the times I see it name=Frontage Road ref=US 29 this will be rendered in similar way as on other maps. Name is on the street and US, I, is on a shield. Doesn't make sense to duplicate the ref on the name. for the rest of the proposed changes in previos mails of the thread I'd say go ahead and do the changes. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] How do I turn JOSM's tiger:reviewed=no highlight off?
you can compile JOSM yourself and edit the default style at ./styles/standard/elemstyles.xml If this is too complicated I can send you a Josm binary with these changes. On 2 Aug 2010, at 1:19 , Nathan Edgars II wrote: If a way is tagged tiger:reviewed=no, JOSM puts a highlight behind it, and when you select it the red is a lot fatter. How do I disable this? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How do I turn JOSM's tiger:reviewed=no highlight off?
On 2 Aug 2010, at 1:50 , Sebastian Klein wrote: Nathan Edgars II wrote: If a way is tagged tiger:reviewed=no, JOSM puts a highlight behind it, and when you select it the red is a lot fatter. How do I disable this? You can put color.mappaint.standard.tiger_data=#80808000 in your advanced preferences. This makes the highlight 100% transparent, however the selection is still fat. Another option is to modify the default style and simply remove the tiger style rules. For this you copy http://josm.openstreetmap.de/browser/trunk/styles/standard/elemstyles.xml to some folder, fix it in a text editor and then simply load the style from the preferences. (Make sure to untick enable build-in defaults.) shouldn't custom or country specific style be maintained in an external style anyway? there is no good reason to have tiger, opengeodb, … in the default elemstyle. I had a trac ticket for tiger but has never been committed. If there is interest I can provide a patch. But I don't know where the custom style should be placed to make it accessible to anyone. As far as I understand JOSM this would be hosted on an external site and not built in to the program. Sebastian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Directional Prefix/Postfix Proposal
On 31 Jul 2010, at 21:58 , Kevin Atkinson wrote: On Sat, 31 Jul 2010, Val Kartchner wrote: On Sat, 2010-07-31 at 21:31 -0600, Kevin Atkinson wrote: On Sat, 31 Jul 2010, Val Kartchner wrote: 1) I agree with most of your proposal. a) Your proposal doesn't take into account cases where there is both a name and a numeric designation for a street. An instance in Ogden, Utah is Washington Boulevard and its alias 400 East. In both cases doesn't a directional prefix apply. However, to avoid ambiguity with the _prefix tag. How about this rule. The _prefix and _suffix apply to all name tags. Hence if name_1 is 400 East than name_1_prefix shall be S, etc. So, you're also proposing that the additional name(s) be placed in name_1, etc. No. I'm saying _if_ the name is places in name_1 than use name_1_prefix, if it is placed in alt_name, use alt_name_prefix, etc. alt_name has a specific meaning and shouldn't be used for this. also name_1,2 … was used for Tiger with the same purpose as alt_name. Now if you play around with prefeix, postfix, abbrev or expanded name it's better to use a different tag osm strength is to make this easy. So no reason to overload existing well defined tags with info which doesn't belong there and creates even more confusion. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Mon, Aug 2, 2010 at 2:37 PM, Kevin Atkinson ke...@atkinson.dhs.orgwrote: So I would like to know has anyone tried to get the wiki page changed so that it is not so rigid? feel free to do so, if there is an acceptable agreement or the wiki just doesn't make sense. the wiki is as open as osm. there is lot of wrong info and missing docu about real mapping usage Or do people here really think everything should be expand to the fullest. Really, would anyone say: United States Highway 29. Rather than U S Highway 29 or more likely just U S 29. you know the answer. I think a lot of the expansion is wrong. we should map what is on the ground and what can be verified. If people write address with abbreviations and signs use abbreviations there is no reason to have expanded names in osm In the above example would anyone write out the directional suffix. In fact Alan didn't even know if that would be Northwest or NorthWest. I think typically this isn't part of a name at all. Are people using it in an address for mailing? how is it written in official records? how would anyone do a search for a street? there are many corner cases so there is no simple yes or no At least 1st hasn't been expand to First, etc. But just wait... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, Jul 29, 2010 at 4:11 PM, Dave Hansen d...@sr71.net wrote: So, the guys that actually went out and were nice enough to collect this TIGER data and share it with us have names for all these things: TLIDs. That's a pretty concrete, real-world meaning to some people. Not in osm context. DB id from an external DB are useless in osm. any can edit them. ways are merged and split over time many of them don't reflect any link to the tiger tlid anymore. it's just filling the planet files. I't is nice to have such a reference on the initial import but there is no use to keep them after edits. If we had changesets at the time it was imported then this is the place to add these tags. there they are readonly and don't fill the planet with useless info ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
Just for that short little bridge? This info should be right (which means *one* tlid) or it shouldn't be there at all. We shouldn't keep this crap around just for the hell of it. By deleting it you're not making it more correct. Never said I was. But deleting incorrect information is better than leaving it around, even if it isn't as good as correcting it. full ack How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 11:24 AM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: I really don't understand your argument. It's the nature of OSM that many people will contribute many types of data, much of which will not be cared about or understood by the majority of consumers. What's wrong with that, and why do you think removing it because you don't understand or like it is acceptable behavior in a crowd-sourced environment? importing is not crowd-sourced! we should apply different rules here. what is wrong normally might be a very good thing for imports and the other way round The only reason that makes sense might be it's wrong. In the case of tiger:*, it's not wrong. It's in its own namespace because it indicates the value as it was in another database at the time of import. Not that I believe we need to justify it, but the three (at least) of us arguing to keep the tags in this thread, each for reasons that we've described, should be sufficient to prove that someone needs the data, and you really have no right to stomp on our work, or data that we need for our work. Also, we're not alone - many people recognized the need to fix the way names are stored. Having to go back to history will be adding an order of magnitude to the complexity of that. if you need them use a native tiger DB, working through history is such a pain that it doesn't make sense. GIS experts will know how to do this and can easily compare osm data with another DB. Have a look at tagwatch and you'll see that tiger:* is just one of many such import namespaces, most of which you are not likely to care about, whether they are doc'd or not. other trash doesn't make these tags more useful. We have all learned from early imports and since then changesets have been added to the API0.6 tiger import was done before and we can't blame anyone. but now we can do it better and fix old mistakes ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 1:12 PM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: At 2010-07-30 12:56, Apollinaris Schoell wrote: How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by Hopefully, you were talking about this specific case only, and not all tiger:*=* tags? Even still, matching the chain of TLIDs to the ways on either side may still prove to be useful at some point. Do we really need the database space that badly? Shouldn't an analysis be done to understand just how much space that is, what the server load will be, how much it expands the history, etc., as was done with the justified removal of tags from the nodes? personally I think all of them. there is no value after editing. usually I keep tlid, zipcode, county, name_type even that this isn't very useful there can be still some use if an application doen't yet use county polygons or there is no info about zipcode otherwise in osm longterm even these should go away. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
On Thu, Jul 29, 2010 at 8:29 AM, Brad Neuhauser brad.neuhau...@gmail.comwrote: Regarding Matthew's earlier point (Agreed. There is no observation that will tell you whether a road is more important than another road that is not where you are. But you can identify physical characteristics. this is not true. There is plenty of observation to tell the importance. But this can't be done by armchair mapping. You have to know your area and it will be crystal clear which roads are more or less important. local knowledge is key for a good map. OSM is crowd sourcing and not let's draw some maps from aerial pictures or create a copy of tiger or other free data. there is no benefit if we use osm just as a container for freely available data. google is much better in doing so with their massive capacity and money. So let's make a better map not a me too map and not try to resolve a problem which can't be resolved by discussion or an algorithmic approach. road tagging is never objective. Not in US and not in Europe, and even much worse in many asian countries. it's a bit more consistent in Europe, but even there are many exceptions. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
As a general concept this is bad but in many cases a very good idea. many tiger roads are completely wrong and there is absolute no value to keep any of the tags. if a mapper does a significant change and is essentially just keeping some nodes and the name tag then it's better to remove any reference to a bad source. a lot of tags for tiger uploads have no benefit and can be removed too without loosing any valuable info. examples are tiger:source tiger:upload_uuid and probably also tiger:separated tiger:county, with county borders available this is no longer useful On Thu, Jul 29, 2010 at 10:12 AM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: A couple of different users have recently been removing all the tiger:*=* tags from roads in the process of other edits to them. One responded that it was because they were sometimes wrong (which is, of course, true, for those roads that we've corrected) and that they did not seem to provide any useful data. However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. AFAIK, we haven't (yet) agreed that these tags should be removed, right? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Soll jede Autostraße als highway=tru nk gekennzeichnet werden?
On 23 Jul 2010, at 9:53 , Boris Cornet wrote: Hallo! Today (Friday, July 23, 2010) at 09:31 your email client emitted: Und glaub mir, die B100 ist durchgehend vom Charakter her eine primary, so wie auch die Reschenstraße (B180), wo es schon mal die gleiche Frage gegeben hat. Es gibt ab und zu ein paar kreuzungsfreie Anbindungen, aber zumeist sind das ganz normale Kreuzungen, manchmal sogar ohne Linksbabbiegespur. Reschenstrasse ist in einem kurzen Abschnitt Schnellstrasse, zwischen Prutz und bis nach Pfunds. Eigentlich sollte das schon trunk sein. Da gibt es keine Kreuzungen. OK, macht doch aus allen Straßen einen bunten Flickenteppich! Was zum Kuckuck soll an der Reschenstraße denn auch nur in irgend einer Art an eine Schnellverbindungsstraße erinnern? Es gibt keine Richtungstrennung, nur jeweils eine Fahrbahn, keine überbreiten Fahrspuren, keine Pannenstreifen…. trunk ist doch gerade dafür gedacht oder nicht? Sonst müsste ja auch fast alle anderen derzeit als trunk getaggte Strassen wieder zu primary getaggt werden. Es ist jedenfalls a Autostrasse beschildert. Und Flickenteppich macht ja der Renderer nicht die DB. Also wir sollten schon möglichst an der Realität bleiben. Und wenn der Ausbauzustand nun mal so ein Flickenteppich ist dann ist das halt so. Google rendert solche Dinge auch so. Nur verwenden sie weniger schreiende Farbkontraste und es faellt normal nicht so stark auf. Wenn das Kriterium kreuzungsfreier Ausbau schon ausreichend für Trunk ist, dann können wir gleich anfangen, halb Österreich zu ändern, und das macht dann auch nicht bei Landesstraßen halt, das geht dann runter bis zu unclassifieds! Detto der Landecker Tunnel, Nachdem im Tunnel Mautpflicht gilt kann man das vielleicht als motorway belassen. Laut Bundesstraßengesetz ist der Landecker Tunnel Teil der Inntalautobahn A12, also ist er richtig als motorway getaggt!! Er war übrigens früher früher als trunk getaggt, bis zu dieser Diskussion: http://lists.openstreetmap.org/pipermail/talk-at/2010-February/001893.html nur von der Priorität und Ausbauzustand eben gleich dem Abschnitt wo es als Autostrasse beschildert ist. allerdings müsste dann auch die S16 Arlbergschnellstrasse in weiten Teilen als motorway getaggt werden. Ach, ja, dann soll die Straße alle 10 km die Farbe wechseln, sogar mitten zwischen Ausfahrten??? Das ist doch sicher nicht dein Ernst. wie gesagt warum nicht. kann ja jeder den style verwenden den er will. der Mapnik style ist für nicht Engländer ohnehin grauenhaft. Es gibt in nirgendwo sonst einen ähnlichen Farbmix auf Karte oder Beschilderung. Schau dir die S16 einmal an, es sind alle Richtungsfahrbahnen perfekt erfasst! Gut, trotzdem schadet es nicht wenn der highway tag stimmt. Mir ist das ja egal solange es halbwegs konsistent ist aber nur an den 3 Beispielen sieht man, dass das nicht so ist. Wenn strikt nach STVO getaggt wird dann ist die S16 soweit ich weiss durchgehend Autostrasse und damit trunk, Damit wird eben auch die Reschenstrasse Abschnittweise trunk. Wenn wir nach Ausbauzustand taggen ist die S16 eben ein mix aus trunk, motorway und eventuell sogar primary. Bin schon länger nicht durchgefahren und bin nicht sicher ob da noch ein paar kurze Abschnitte fehlen. -- Bye Bye, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Soll jede Autostraße als highway=tru nk gekennzeichnet werden?
On 23 Jul 2010, at 11:23 , Boris Cornet wrote: Hallo! Als ich versuche es noch ein letztes Mal! Es geht darum, ob stinknormale Bundesstraßen, die abschnittsweise als Autostraße ausgewiesen sind, als trunk getaggt werden solen oder nicht. Vorneweg: für Autostraßen gibt es einen eigenen tag: motorroad=yes Die Klassifizierung der Straße hat NICHTS (ich wiederhole: NICHTS) mit dem Ausbauzustand zu tun, sondern einzig und alleine mit der Verkehrsbedeutung! Wer's nicht glaubt, dazu gibts ein ausgesprochen erfolgreiches proposal und es steht auch zig-mal im wiki! dein Zitat: Laut Bundesstraßengesetz ist der Landecker Tunnel Teil der Inntalautobahn A12, also ist er richtig als motorway getaggt!! Er war übrigens früher früher als trunk getaggt, bis zu dieser Diskussion: http://lists.openstreetmap.org/pipermail/talk-at/2010-February/001893.html dass jetzt die Verkehrsbedeutung der Reschenstrasse in Fliess um 2 Klassen ändert ist schon an den Haaren herbeigezogen. Wenn schon Verkehrsbedeutung dann auch halbwegs konsequent und konsistent. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] fact-based vote?
On 17 Jul 2010, at 2:05 , Heiko Jacobs wrote: I cannot accept a process with loss of data. If there is a loss of data I will leave OSM. there is no loss of data! It has always been said that the old data will remain available under the old license. The only possibility to avoid loss of data (if process proposed isn't changed because of this discussions, I'm still hoping for this ...) is to (ab)use the licence change question as a vote, hoping that reaching the critical mass will fail. Using this vote it might be easyer because they want a really high of percentage of user accepting new licence. If my vote failed and licence is changing with loss of data, I leave the project including my data, because of combination of vote and licence change of my data … strategic voting is really wrong and stupid. playing this game by many will put the project on more risk for nothing. If you think Odbl is the better license vote for it or PD as a third choice. If you don't like the process of how data is converted what is considered minor edits and can still be relicensed without loss … then better raise your voice there. absolutely agree we need to work on a smooth process to minimize loss. There is no decision on this process there is no plan there are just many ideas. So let's make this switch or abandon it as fast as possible. No decision is the worst for OSM. personally I don't mind which of the 2 license we use but we need a clear statement where we go. this took already too long and holds back imports from non PD sources. Puts all consumers of OSM data at risk to have to back out at some time or go a very painful way to mix data from old planet with new Odbl for some time. If it is divided in two questions, the chance of avoiding licence change and lost of date will sink, because only 2/3 or similar is needed(?), the probability that I leave theproject arises, but my data will rest inside OSM … yes, the second question has never been asked, so why do you expect an answer. and again data is not lost. I am sure the OSMF has the same wish as you and I and will come up with a reasonable plan when the first is answered positively. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] FW: [osm-professional] Regional Street Centerline Solution - Minneapolis- St. Paul metro area - RFP
On 13 Jul 2010, at 6:34 , Ian Dees wrote: On Tue, Jul 13, 2010 at 7:39 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: For example: - The proposal requires unique, persistent IDs for landmarks/points of interest. OSM does not have an accepted way of storing persistent IDs. there is a wikipedia project trying to achieve this. As far as I understand they try to do some local search and pattern match of tags. But there is no way to get persistent ID. A POI node can be changed to to a way or relation whenever better knowledge allows to do this. - Addressing information (even if it is address ranges) is a necessity. Anything we can do to make entering address information easier and more interesting would increase the usefulness of OSM for a much wider range of people. this is a lot of work and given that Tiger offers address interpolation already there is not so much incentive to do this. building an address DB based on Tiger provides a consistent quality but anything in osm will vary widely. In the long term individual address data will be useful for osm. But this is a huge project and will need 10-100x more active mappers at least. some counties or cities may provide such data. Then we can for sure import it. - Updates and changes that are accepted into and created from the dataset need to be stored somehow in a status database. This sounds a lot like our history page, but the history page is full of changesets that don't have changes in the region. As has been discussed before, a tool to view a real history for an area would be useful. should be easy to implement by parsing minutely/hourly diffs. the history page requires queries to the main DB and if someone starts to do heavy access they might get blocked by the admins Having said that, does anyone want to work with me on a proposal, even if it only ends up giving us feedback on our data from a real external group? the way osm works is so different that this doesn't make much sense. a DB where anyone at any time can modify, delete data will require constant tracking for which they will definitely need their own db. So why even bother with osm at all. using the osm toolchain is an option which can make sense. then all kinds of extensions like limited access for can be implemented. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] FW: [osm-professional] Regional Street Centerline Solution - Minneapolis- St. Paul metro area - RFP
On Wed, Jul 14, 2010 at 9:46 AM, Ian Dees ian.d...@gmail.com wrote: On Wed, Jul 14, 2010 at 11:29 AM, Apollinaris Schoell ascho...@gmail.comwrote: the way osm works is so different that this doesn't make much sense. a DB where anyone at any time can modify, delete data will require constant tracking for which they will definitely need their own db. So why even bother with osm at all. using the osm toolchain is an option which can make sense. then all kinds of extensions like limited access for can be implemented. Part of the point I was trying to make was that if our response to requests like this is always something along the lines of the way OSM works is different so it doesn't make much sense, then maybe we're doing something wrong. Who will use our data (beyond plopping OpenLayers down and using OSM tiles) if there are no tools to allow it to work with outside entities? the whole point of starting osm was to do things different. to allow editing for non GIS folks, make new things possible. If someone needs traditional GIS then use traditional GIS. They want shape import and shape export. Any GIS system does this out of the box. if osm provides more or better data there will be users for it. users will combine public data from other sources and osm data. I see absolute no reason to dump all public data to osm just because it exists, maintain an external version control and do a conversion back to traditional GIS. as soon as data is exported from osm it is tainted with the license and will never be of much us for such projects. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Gemeindegrenzen
2010/7/7 Peter Holzleitner pe...@holzleitner.com IMHO ist nur die zweiter Variante richtig, denn dass es sich um eine Gemeinde handelt, geht ja aus dem admin-level (indirekt) hervor. Nein. Der Name *ist *Gemeinde xyz oder auch Marktgemeinde xyz oder Stadt abc was auch immer. Wirklich? Also da waere eine Quellenangabe hilfreich. So ist das nur eine Behauptung die bis jetzt ziemlich alleine da steht. Schau mal die AMAP an. Da wird definitiv nur der Name gerendert. Und das ist wohl die Referenz fuer Karten in AT Ortstafeln zeigen auch nur den Namen. Und nein, wir taggen nicht für Renderer, aber wir erwarten auch nicht, dass ein Renderer einige zigtausend Wissensregeln über lokale Gebräuche haben muss, damit eine brauchbare Karte herauskommt. Und wie anders soll man verhindern, dass kommentarlos Hintertupfing auf dem Acker steht??? Es schreibt ja auch niemand Berg xy oder Gipfel xy oder Fluss xy ... auf eine Karte. Dazu gibt es einen einheitlichen Style mit Symbolen und eine Legende die das erklaert. --P ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Licence of Soviet military topographic maps
just checked one of these maps. and interestingly it contains data which is most likely copied from official maps which are not in PD. So it is nearly impossible that these maps are PD. the russian copyright holder may have bought the source data but very unlikely they have a license for distribution and release to PD. On 23 Jun 2010, at 23:48 , Kirill Bestoujev wrote: Did they show you any documents confirming that that do really have ANY rights to sell those maps? I\m sure they did not... K. 2010/6/24 jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com: We purchased them from this site : http://mapstor.com/ Here the same data is available from a usaid sponsored project : http://www.bunkertrails.org/maps.php On Thu, Jun 24, 2010 at 8:28 AM, Eugene Iline evge...@ily.in wrote: Have you really officially purchased them from Russian government, its military divisions or perhaps from Roskartografiya? 2010/6/24 jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com On Thu, Jun 24, 2010 at 7:42 AM, Kirill Bestoujev bestou...@gmail.com wrote: No, they are not out of copyright. All the rights of USSR were transfered to Russian Federation. Neither USSR, nor Russian Federation ever transferred those maps to public domain or in any other way allowed free use of them. Most of that maps were stolen from exUSSR military bases in republics, which separated from USSR in 90-s. In Russia disclosing of such maps (not 100k, they were openly publiched, but 50k) is still a crime - treason. There was such a case a month ago. SO: old USSR military maps are not allowed to be used in OSM. Oh really? I read that they were sold. We had purchased them and were using them, also for osm. The consensus was that they are public domain. lets straighten this out. http://www.mail-archive.com/talk@openstreetmap.org/msg27951.html mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Best regards, Eugene Iline ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] US BLM Designated Wilderness
I have added most for state parks but didn't have a source for national parks and special areas in there. So yes a good plan to add them. also it's good to remove the nature_reserve tag from the park itself and keep it only for designated areas. initially parks have been added only to show up as big green areas. Now with more and more details it's my favorite to define the park itself as a boundary and add details like nature_reserve and vegetation. One recommendation. don't add the name to the area and a node with the same name like this node node id='795304353' timestamp='2010-06-29T04:07:52Z' uid='191585' user='Erik Burrows' visible='true' version='1' changeset='5103001' lat='35.381583' lon='-115.64253' Rendering will create name duplicates whenever there is enough space. If you need a reference to crosscheck the quality of the data check out http://www.greeninfo.org/ they have not yet agreed to open their license for osm but might do so in future. it's the best reference for all areas open for the public in CA On 29 Jun 2010, at 18:14 , Erik Burrows wrote: I just added a group of designated wilderness areas to the database, in the US Mojave National Preserve area, as leisure=nature_reserve. This differs from national parks in that in designated wilderness areas, mechanized travel and development of the land is usually prohibited. The current Mapnik style doesn't render this clearly differently from national park areas, but could be modified, as I have done to my own slippy map instance here: http://www.erikburrows.com/osm/?zoom=10lat=35.09019lon=-115.57072 I think this first batch of areas went well, though did require removing a park multipolygon relation containing the same leisure=nature_reserve tag. Another boundry relation does the job of designating the area as boundry=national_park. The data is from the BLM (Bureau of Land Management), and so not copyrighted: http://www.blm.gov/ca/gis/ (This link is California only) I'd like to volunteer to import the rest of these designated wilderness areas into the OSM database as a bulk import. Any objections, suggestions, comments? Thanks, Erik Burrows ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] [Talk-us] How is it that a way is deleted but doesn't show up for undeletion? (horribly screwed up area in northern Pennsylvania)
most likely the way itself isn't always deleted. if a way is reduced to a one node way it will be just a single dot on the map. nearly impossible to edit and get the history without seeing a real way and where it should be. Maybe better to revert these whole changesets. This can be tricky if people have started to fix things already. On 25 Jun 2010, at 2:59 , Nathan Edgars II wrote: http://www.openstreetmap.org/?lat=41.73928lon=-79.88822zoom=15layers=B000FTF All around here there are missing ways. I can't tell exactly what happened, but edits such as http://www.openstreetmap.org/browse/changeset/3128411 and http://www.openstreetmap.org/browse/changeset/3125973 (done at about the same time) seem to have majorly screwed up the area. That's bad enough, but if I go to edit and hit U to undelete, I can't find any of these ways. I guess it's possible that they were never imported in the first place, but... http://www.openstreetmap.org/?lat=41.64047lon=-76.87988zoom=17layers=B000FTF Here it's clearer what happened - botched dupe node deletion: http://www.openstreetmap.org/browse/changeset/3138125 At least we've stopped that crap, but the scars remain. ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] How is it that a way is deleted but doesn't show up for undeletion? (horribly screwed up area in northern Pennsylvania)
most likely the way itself isn't always deleted. if a way is reduced to a one node way it will be just a single dot on the map. nearly impossible to edit and get the history without seeing a real way and where it should be. Maybe better to revert these whole changesets. This can be tricky if people have started to fix things already. On 25 Jun 2010, at 2:59 , Nathan Edgars II wrote: http://www.openstreetmap.org/?lat=41.73928lon=-79.88822zoom=15layers=B000FTF All around here there are missing ways. I can't tell exactly what happened, but edits such as http://www.openstreetmap.org/browse/changeset/3128411 and http://www.openstreetmap.org/browse/changeset/3125973 (done at about the same time) seem to have majorly screwed up the area. That's bad enough, but if I go to edit and hit U to undelete, I can't find any of these ways. I guess it's possible that they were never imported in the first place, but... http://www.openstreetmap.org/?lat=41.64047lon=-76.87988zoom=17layers=B000FTF Here it's clearer what happened - botched dupe node deletion: http://www.openstreetmap.org/browse/changeset/3138125 At least we've stopped that crap, but the scars remain. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Licence of Soviet military topographic maps
there is no mention of PD for these maps at mapstore.com. they are not even free of copyright from poehali.net free download doesn't mean PD Can I use the maps in my own project? You have the right to use maps for the purpose of familiarization for personal use. To use the maps or other materials in your project, you have to obtain our permission. Please use our email address i...@mapstor.com for communication. But please note: • All map images contain “poehali.net” imprint, which is our trademark • In order to avoid confusion, there should be clear distinction between your product/service and ours • We would greatly appreciate you citing us as a source of the images • We are always open to cross-marketing and/or link exchange. On 24 Jun 2010, at 3:22 , jamesmikedup...@googlemail.com wrote: I am not saying that. I am saying that this is a topic for lawyers. from what I learned about the discussion on wikipedia datapoints, it is uk law that governs osm data. mike 2010/6/24 Kirill Bestoujev bestou...@gmail.com So you want to say that you do not care for those osm-users, which are in Russia and which may have problems using osm with copyright data in it? Did I get you right? K. 24 июня 2010 г. 13:56 пользователь jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com написал: I think you should take this to the legal list. As far as I know, the copyright laws of england count for osm, not those of russia. mike 2010/6/24 Alexandr Zeinalov shu...@sbin.ru We purchased them from this site : http://mapstor.com/ AFAIK this is not legal seller of maps, and poehali.org too. They both hosted outside Russia. So this maps can't be reliable identified as public domain maps. Here the same data is available from a usaid sponsored project : http://www.bunkertrails.org/maps.php -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- James Michael DuPont Member of Free Libre Open Source Software Kosova and Albania flossk.org flossal.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changed highway=*_link meaning?!
On 24 Jun 2010, at 5:24 , Richard Mann wrote: On Thu, Jun 24, 2010 at 12:32 PM, Andy Allan gravityst...@gmail.com wrote: the root of the discussion seems to have no basis in the tags, and seems entirely to be around rendering artefacts that you dislike. What purpose do the _link tags serve other than rendering? then the rendering is completely broken and doesn't deserve a special tag. all the commercial maps render links much smaller and on lowest layer. If there's a serious reason for tag-to-higher then we can add an additional tag so people can record the status of what it links to (and then we can render it any way we like). But I can't think of a sensible reason for recording/using the higher status, except for motorways, so it just seems like it's been copied from motorway_link without thinking it through, is producing unintended results, and is therefore an error that needs to be corrected. from a rendering point of view this shouldn't matter at all. as said above rendering is ugly for *_link If people have done that thinking through, and there's a genuine reason for tag-to-higher for non-motorway roads, then I'd love to hear about it. All the reaction so far seems to be a complaint about how I did it, rather than the substance of the matter. Andy's made one of the few moderately serious points: it's confusing to treat them differently to motorway links. Not exactly a clincher, if it's wrong for other reasons. consistency is more important to avoid confusion than an absolute statement. as others pointed out ramps to/from motorways and most likely on trunks are in the same jurisdiction and maintained by same agency as the motorway/trunk. So there is a clear evidence that *_link belongs to the higher road it connects to. Richard Mann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Daten vom Katatsteramt: dxf oder shape?
Ich wuerde shape files nehemen. Das ist der am meisten genutzte Standard und es gibt verschiedene tools fuer shape zu osm. ogr2osm kann sogar relationen statt duplicate ways generieren. Und es gibt auch opensource GIS tools um shape direkt zu bearbeiten. On Thu, Jun 24, 2010 at 1:32 PM, Tirkon tirko...@yahoo.de wrote: jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: Ja, siehe dxf2osm (twonickels branch of dime) http://www.mail-archive.com/d...@openstreetmap.org/msg10255.html mfg, mike Ich habe keine Ahnung von der Materie. Heißt das, Du könntest eine dxf Datei in eine osm-Datei umwandeln? I do not have any clue of this technical stuff. Does that mean, that you could convert a dxf-file to an osm-file? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Percentage of data imported vs mapped
In Oregon, 48% of the objects have been most recently modified by
non-TIGER sources. Calculated this way:
grep -o 'user=[a-zA-Z0-9]*' oregon.osm | sort | uniq -c | sort -n | grep
-vi tiger | awk '{sum += $1} END { print sum;}'
grep -o 'user=[a-zA-Z0-9]*' oregon.osm | sort | uniq -c | sort -n | awk
'{sum += $1} END { print sum;}'
It's higher than I expected, personally. Not too shabby.
and how much of it are bots? the real user edits are probably much lower
-- Dave
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] County lines vs. TIGER roads
On 23 Jun 2010, at 21:41 , Val Kartchner wrote: Is there a way that we could get higher resolution county line boundaries from anywhere? I expect not, but I figured I'd ask. I'll plan to continue to correct these manually. depends on your state and county. some offer the data for download. A good source is also USGS maps. But it's more work to trace from them. Also terraserver has many errors. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Failed to download 9.5 GB planet
most likely your OS, or disk partition, or wget can't handle large files. on old unix systems this is usually 2GB. on windows FAT partitions there are also limits but don't know the numbers On 21 Jun 2010, at 9:12 , Juan Lucas Domínguez Rubio wrote: Dear list: I'm trying to download one of the latest planets and I repeatedly get this error message, always after ~1.5 GB, with wget and also using Mozilla Firefox. Any idea why this happens and how to solve it? ... 1583000K .. .. .. 15%1.36 MB/s 1583050K .. .. .. 15%1.16 MB/s 1583100K ... 15%2.90 MB/s 16:23:53 (1.02 MB/s) - Connection closed at byte 1621101924. Retrying. --16:23:53-- http://ftp.heanet.ie/mirrors/openstreetmap.org/planet-100618.osm.bz2 (try: 2) = `planet_100618.osm.bz2' Connecting to ftp.heanet.ie|193.1.193.64|:80... connected. HTTP request sent, awaiting response... 500 ( Arithmetic result exceeded 32 bits. ) 16:23:53 ERROR 500: ( Arithmetic result exceeded 32 bits. ). Regards Juan Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Route Relation Nitpicking
On 16 Jun 2010, at 21:26 , Zeke Farwell wrote: On Thu, Jun 17, 2010 at 12:03 AM, Richard Welty rwe...@averillpark.net wrote: i think the rendered pseudo-shields probably need to show some reference to the network the highway is in, otherwise you'd not know what kind of shield you're looking for. Yes, to be clear I was not suggesting that network prefixes are a bad thing for a renderer to show, just that I don't think they belong in the ref tag. I don't see why a renderer can't use ref and network to display US 7 or 7 on a US shield graphic. mentioned earlier already. the ref tag is taken by a standardization in osm worldwide. sure osm is free and everyone is allowed to change things but then don't expect to get any useful rendering anywhere. it doesn't matter if it's technically possible. if a different tagging is needed then introduce new tags or use a namespace like ref:don't like the old tag and=7 don't tag for a specific renderer and more important don't tag against all existing renderer ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Q: Is OSM interested in neighborhood and regional boundaries for L.A.?
I think it's a good idea but needs a good idea for the tagging with these different combinations and dividing. neighborhood names are common in other cities too and well known to locals. So it is valuable info for osm and should be rendered too. currently some are added as place nodes and also rendered as such. having them as an area is even better. sure there will be debates about exact boundary but over time either osm converges to the locally used ones or osm will tell people where they are and they may get used to follow osm On 16 Jun 2010, at 6:13 , Ben Welsh wrote: At the risk of over complicating things, let me give a little more info. LA County is a fragmented place with many different cities and unincorporated areas puzzled together. Our neighborhoods are in fact three different types of areas consolidated. 1. Cities divided into neighborhoods. i.e. http://projects.latimes.com/mapping-la/neighborhoods/city/los-angeles/ 2. Complete cities, drawn by their formal boundaries. i.e. http://projects.latimes.com/mapping-la/neighborhoods/neighborhood/west-hollywood/ 3. Unincorporated areas that are Census Defined Places: http://projects.latimes.com/mapping-la/neighborhoods/neighborhood/east-los-angeles/ On top of that, there are dozens of small unincorporated areas that are basically islands floating between everything else. We've lumped them in with a bordering neighborhood: http://projects.latimes.com/mapping-la/neighborhoods/unincorporated/list/page/1/ Why did we throw all these together and call them neighborhoods? Because our goal is to have a single common denominator we can spread across the entire county and use for comparison. That's why we build them out of Census tracts, so we could rack up demographics about them all. i.e.: http://projects.latimes.com/mapping-la/neighborhoods/income/median/neighborhood/list/ As time goes on, we plan to divide up all of the cities into smaller neighborhoods, not just Los Angeles, we did in a first round last year. In cases where cities have official hood boundaries (LA does not) we'll likely use those. More info about the project and process is here: http://projects.latimes.com/mapping-la/neighborhoods/about/ On Wed, Jun 16, 2010 at 5:23 AM, John F. Eldredge j...@jfeldredge.com wrote: This sounds like a good compromise to me, as most people will have a general agreement of where a given neighborhood is located, but differ about where the boundaries are located. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria -Original Message- From: Ed Avis e...@waniasset.com Date: Wed, 16 Jun 2010 08:46:09 To: talk@openstreetmap.org Subject: Re: [OSM-talk] Q: Is OSM interested in neighborhood and r egional boundaries for L.A.? A compromose would be to add the centre of each neighbourhood (as locality=place or similar) but not the exact boundaries. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- palewire.com work: 213-473-2624 cell: 213-254-5570 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing on OSM maps on a Garmin device
On 15 Jun 2010, at 6:45 , Maarten Deen wrote: On Tue, 15 Jun 2010 15:20:07 +0200, Lambertus o...@na1400.info wrote: On 2010-06-15 01:53, Liz wrote: On Mon, 14 Jun 2010, Maarten Deen wrote: Does anyone have similar experiences, and maybe an explanation why this happenes? Are the OSM maps too detailed for a simple device like this to calculate? Using a separate *set* of maps for Australia, I have had trouble with calculating a route that crossed a border from one map in the set to another. The distance involved is not the problem in this case, but the existence of the border. That could be a result of the method used to split the data. If you use the Mkgmap Splitter tool then crossing borders should be possible, but using Osmosis et al won't. And it would explain it only partly. I know the Garmin map does extend some distance into Germany in detail, but it also covers Europe in low detail. So you would expect to get some form of route, albeit not very accurate, and the device would not show you on the road. But it does not explain why I got a route to my first waypoint from the start (likely to be outside of the Garmin map, but I'll have to check that) and not when, after I was well and truly in Germany and on the OSM map, I chose not to follow the route and it could not recalculate the route. Nor does it explain why I got a route in economic route mode and not in fastest route mode. And the maps from All in one Garmin Map are also made with Mkgmap, so the problem shouldn't occur anyway. this is a known problem but unknown reason and solution. sometimes garmin devices can't find a route adding additional through points help. did a route recently from south of germany to north. one trough point on the first route was sufficient. then I planned a different version and it did not work even that I had an additional through point after both routes where supposed to merge already. so calculating the first portion of the route influenced how the rest was calculated. My guess is that garmin devices have either not enough memory or they use a recursive algorithm and the stack size or number of recursions is limited. btw mkgmap mailing list is the better place to discuss these topics Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Route Relation Nitpicking
On Tue, Jun 15, 2010 at 10:45 AM, Phil! Gold phi...@pobox.com wrote: I started experimenting with rendering route shields the other day, and I figured it would be nice to use route relations as my source. The wiki says that the ref= tag on a relation should not include the network identifier[0], which makes sense, since there's a separate network tag. When I looked, though, I found a lot of relations putting it in (as well as other things, sometimes--US 1 in Maryland had a ref of US 1 (DC/MD/PA), which I moved to the name= tag (which might still be incorrect, but at least it's less incorrect)). in osm there is no such thing as correct. everything is allowed. there are only agreed standards. but for route relations there is just a mess. up to now they aren't used anywhere so it doesn't matter. if you prepare a good rendering it will be an incentive to standardize. How consistent are the US route relations? Should the relations with network information in the ref= tags be updated, or should the wiki be changed to document current behavior? wiki should be updated. reality of many mappers should rule over wiki written by one [0] I note that this is the opposite of the ref= tag on the roads themselves, where the network info is included and it seems there are debates as to whether dashes or spaces should separate the network and number. it should be easy for mappers as first priority. if it's good for software even better. with 2 tags there is no discussion about separators and it's also easier to combine them in the desired format. also typos like 2 spaces instead one will be less common -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- Gift of the Magi LITE(tm) by O. Henry A husband and wife forget to register their gift preferences. --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Small village high detail low angle orthorectification
On 13 Jun 2010, at 6:46 , Tristan Scott wrote: Does anyone have experience of this, who could point me in the direction of the appropriate JOSM plugin, or external software? I have Linux (Gentoo) and Windows XP on systems used for mapping. Qgis is good for that. you can download or import osm data and rectify by choosing points from osm data. didnt't manage to edit any osm data directly in osm. instead create a new layer, export as shape and convert to osm for editing in josm. but this is not very accurate and can be used only with a lot of guessing and local knowledge This must be a fairly common issue for mappers, right? Tristan Scott BSc(Hons) Yare Valley Technical Services 07837 205829 01603 858441 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Best sources for boundary lines?
On Mon, Jun 14, 2010 at 1:55 PM, Nathan Edgars II nerou...@gmail.comwrote: (note: I'm talking about boundaries that have stayed in the same place during recent times, not those that change every year by annexations.) While the TIGER data is pretty good for these boundaries, it has some precision issues. For example, at http://www.openstreetmap.org/?lat=40.81072lon=-74.06072zoom=16layers=B000FTF the line is shown following Paterson Plank Road over the Turnpike, while USGS places it on the former pre-Turnpike alignment of the road: http://mapper.acme.com/?ll=40.80869,-74.06204z=16t=T Other (probably unusable) sources such as http://gis.co.bergen.nj.us/appbase/ and http://www.state.nj.us/transportation/gis/maps/bergen.pdf agree with USGS. So the question is: for boundaries that have not changed since the USGS topos were created, can it be assumed that they will be more precise than the TIGER data? Are there any other usable sources that will be more precise than TIGER? my experience is that TIGER is the worst. USGS also matches with natural features fences, ... where this can be checked against Yahoo sat images. for better data you can try to get state/county data. be careful to use USGS from terraserver. a couple of areas are shifted or randomly stretched. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Best sources for boundary lines?
On Mon, Jun 14, 2010 at 4:19 PM, Nathan Edgars II nerou...@gmail.comwrote: On Mon, Jun 14, 2010 at 7:10 PM, Apollinaris Schoell ascho...@gmail.com wrote: my experience is that TIGER is the worst. Well, there's certainly worse, such as the USGS 2001 County Boundary import, which has way too few nodes to get any sort of precision. I've been replacing this with 2008/2009 TIGER data. forgot this one, have replaced it entirely already in CA with official state data ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] GroundTruth Planet Contour - Super script
I have a perl script to create tiles based on srtm data. for usa based on ned data and some tiles based on viewfinder data because srtm is really bad in mountain areas tools required are gdal_translate, gdal_contour, shp2osm, mkgmap. processing time and temporary space requirement is huge. If someone can provide a host for sharing the tiles I can run it. Or if someone is interested can share the script. I have used 25m contours and then all tiles I have processed can be done with 1x1 degree and they still fit into a single .img file. On 9 Jun 2010, at 2:21 , Sam Vekemans wrote: Hi everyone, I know that this is slightly off-topic, however, this is something that everyone who uses a Garmin GPS that uses IMG files, needs uses when traveling in areas, as a contour map is needed. Right now, i manually making the 1x1 degree contour map IMG files for Japan. (as a break from all of Canada) (at a set 10m interval) using this basic DOS script, and manually changing the ComputerTeddy tile #'s and bounding box the name of the tile area (using a recognizable location within the tile area). http://wiki.openstreetmap.org/wiki/User:Acrosscanadatrails#MapSource_Contours Does anyone know of a way to run a script that will process the entire planet host them on a server somewhere (just as the ComputerTeddy OSM tile data is)? It would certainly be a great benefit to have this as a resource for people. ... and this will only be a 1-time process, as the contour source doesn't change that fast. I'm planning on using archive.org medafire.com to host the Canada Data, as the tile names numbering system is already defined in it's own NTS form. Again sorry for the off topic, Hopefully someone can help make this happen. Sam Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] On the ground rule on the wiki
On 31 May 2010, at 21:31 , Knut Arne Bjørndal wrote: On 31. mai 2010, at 21.13, Ian Dees wrote: On Mon, May 31, 2010 at 2:06 PM, Gustav Foseid gust...@gmail.com wrote: How do, on the ground, you verify the name of a peak? You look at the sign. Talk to the hikers you passed on the way up with your GPS. How do you, on the ground, verify a national park or nature reserve? It sounds like you're talking about the border of the park or reserve. As has been said before, borders probably don't belong in OSM. The name of a park is probably verifiable though. All of these things might be properly marked with signs where you are, but they certainly are not everywhere. If they are not marked, how do the locals know what and where they are? Please, take a vacation outside densely populated areas. Northern Norway is quite nice: http://osm.org/go/1KyNf-- Names are often passed by word of mouth, or learned from a map. You /might/ find some signposted peaks, but I doubt it. word of mouth is normally the original source and a name on map is derived from it. so it can be verified. and what is on the ground is the feature itself. the rule can't be applied to every tag. very few values can be verified on the ground If we are supposed to leave out every name that isn't signposted we might as well just give up on creating anything like a nice hiking map for Norway right away. And if we aren't doing anything but roads we might as well use Google maps, they are quite good at that. -- Knut Arne Bjørndal aka Bob Kåre bob+...@cakebox.net bobk...@irc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Tagging of county roads
On 27 May 2010, at 16:12 , Frederik Ramm wrote: Apo, Apollinaris Schoell wrote: totally disagree. if osm doesn't open itself more to non geeks the project will die as fast as many other open source or crowd source projects. Citation needed ;-) this in't a german wikipedia article, posts are personal opinions not facts There are different strands in this argument: 1. Should we use human-readable tags. My answer is yes definitely. But this has nothing to do with making things simpler for non-geek users; au contraire, non-technophiles will depend very much on shiny UI that shields them from any tag, human-readable or cryptic. Having human-readable tags is important for the geek users who want to grep through their XML or place tags by hand. usability on all levels is important. the absolute newbie will use Josm, Potlatch presets. and learn the key-value pairs easily. but if we do heavy translation into cryptic codes this makes it difficult for no reason. Why does osm use xml instead a binary format like shape? it opened the GIS world to all kinds of people with technical skills. Going forward we need also attract normal people and some of them may turn into experts. Building artificial walls anywhere from POI adding to imports, writing bots, … is bad. Wherever there is no good reason to make things complicated let's keep it easy for any experience level. 2. Are we in a decline because we are not open enough to non-geeks. My answer is no, we are not in a decline, we are growing and this is supported by statistics. I challenge anybody to show me an area of OSM which is actually in decline or even in stagnation (as opposed to not growing as quickly as someone has hoped). Mike answered this already, and this is easy to prove. activity on talk-us is practically 0, compare it with and canada and their population size it's obvious, the number of active mappers is only a handful even in large metropolitan areas. 3. Will the project die if it does not open itself more to non-geeks? Possibly, after the geek population has been exhausted, but that is going to be some time. I don't think any kind of drastic action is needed. This ship sails along nice and steady, and we need sailors to do all the work, but we don't need drastic course corrections. I didn't call for drastic action at all. I am not SteveC. All I like to see is to do things in a way that we don't scare away mappers and back to the initial topic don't map for the renderer Keep up the good work is the motto, and OSM will prevail. Bye Frederik ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging of county roads
On 26 May 2010, at 10:11 , Alan Mintz wrote: what does the S mean in the ref? It's just a part of the reference numbering. County road references are a letter followed by one or more numbers, and this is how it's signed (see http://en.wikipedia.org/wiki/County_Route_S18_%28California%29 for the example mentioned below). is it a state route or a county road? I'm talking about county roads, not state routes. In other counties in CA they are J, never seen the S for county roads. good to know I think most use CA for state hw. It's hard to tell if this is correct. Even hw shields are inconsistent. most shields in california use the number only but some shields and official documents use other abbrev like SR. I think to match the what's on the ground rule we should change CA to SR, but it's very common across US already and only if there is a broad consensus this should be done It seems you are talking about state routes here, not county roads. yes, similar situation tough. quite inconsistent in reality and in osm Does it make sense to add a network=US:CA:Orange tag (like the relation) instead of the is_in:* tags? this is as wrong as is_in tags, someone invented it to tag for a renderer. network=Orange should be sufficient and correct. But there are counties named Orange in other states, which is why I want to include the state somehow - it's as important a part of the complete reference as the county. not really needed, the state and country polygons with the coordinates define where it is. sure there is some redundant info in osm and it doesn't harm to have more data. in general the better tag structure and very common approach is to define a namespace like this network=Orange network:state=CA (or california to make it human readable) network:country=US, but this is probably overkill this is much easier to understand for humans and it is easier to parse by applications. packing all info into a single tag value by some cryptic codes is tagging for a specific application. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging of county roads
On 26 May 2010, at 24:25 , Alan Mintz wrote: It seems that the county road number should go in the ref tag, and this is what I've seen in some cases, but where should the county and state go? I've used is_in:county and is_in:state_code in the past for other things (like bridges and mileposts), but people don't seem to like these, and they're not exactly right - I'm not trying to say where the roads are, just complete the reference tag with what's on the signage. you answered already, is_in is wrong for this purpose. the ref tag is the place to use. Currently, for example, I'd tag Santiago Canyon Road in Orange County, CA, as: highway=secondary ref=S18 is_in:county=Orange is_in:state_code=CA what does the S mean in the ref? is it a state route or a county road? I think most use CA for state hw. It's hard to tell if this is correct. Even hw shields are inconsistent. most shields in california use the number only but some shields and official documents use other abbrev like SR. I think to match the what's on the ground rule we should change CA to SR, but it's very common across US already and only if there is a broad consensus this should be done Does it make sense to add a network=US:CA:Orange tag (like the relation) instead of the is_in:* tags? this is as wrong as is_in tags, someone invented it to tag for a renderer. network=Orange should be sufficient and correct. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Vorankündigung: OSM am OpenSourceDay (28. Mai in Innsbruck)
On 14 May 2010, at 15:47 , Boris Cornet wrote: Apollinaris Schoell schrieb: Das waere doch endlich einmal die Gelegenheit Wolfgang freundlich! zu bitten die source Daten von plan.at http://plan.at der community zur Verfuegung zu stellen. Darum schreibe ich auch, bitte kommt massenhaft. Ich kann gut verstehen dass er zu dem Thema keine Kommentare mehr in diesem Forum gegeben hat. Die Kritik war teilweise schon ungerechtfertigt ... Ich nicht. Mein Vorstoß im März 2009 war es eben, die Rohdaten in irgend eine Form zu bekommen, um dann den Import langsam und geordnet zu wiederholen. Die Antwort war ein schnippisches Was würdest du wohl mit ACAD Daten tun? und als ich zurück schrieb, dass ich seit Jahren mit GIS und Datenkonvertierungen zu tun habe, kam nichts mehr, seither sitzt Hr. W. im Schmollwinkel. Als du gefragt hast war es schon zu spät. Da hatte er schon lange abgeschaltet. War ein Wunder dass er überhaupt noch geantwortet hat. nur so als Beispiel welcher Ton da angeschlagen wurde http://www.mail-archive.com/talk...@openstreetmap.org/msg37061.html Ausserdem hat er derart haarsträubende Fehler gemacht, und auch den Import vollkommen anders als vereinbart durchgeführt, dass er sich Kritik nun weiß Gott gefallen lassen musste. es sollte uns allen klar sein dass wir das alles in unserer Freizeit machen. Ohne seine Arbeit wäre vieles bis heute nicht gemacht. Auch wenn viele Fehler gemacht wurden es ist besser als nichts. Und wer glaubt es besser zu können kann ja einfach plan.at daten löschen. Bearbeitung war explizit erwuenscht und das haben wohl einige nicht gelesen oder nicht verstanden die erst spaeter eingestiegen sind. ... nur dass die Bearbeitung massiv erschwert wird durch die Tatsache, dass die Importdaten mit den bestehenden verknüpft wurden. Das war halt sehr ambitioniert und da wo es funktioniert hat auch ganz gut. Aber in anderen Bereichen sehr schlecht. Aber nochmals wer es nicht mag kann das in Josm in 10s selektieren und löschen. Massen importe sind immer problematisch und fast alle sind gleich schlecht oder noch viel schlechter gelaufen. Ein import sollte immer nur osm files generieren und die community kann das dann lokal verifizieren und Stueck fuer Stueck einbauen. Exakt so war's ja geplant, aber… Das wäre mir neu. Er hat soweit ich weiss alles alleine gemacht. Es hat eineinhalb Jahre gebraucht, den Bezirk Innsbruck Land vom Mapspam zu säubern. Einen geordneten Import durchzuführen, hätte wohl weniger als die halbe Zeit gekostet, und das Ergebnis wäre sicher auch besser geworden. Definitiv, die meisten importe schaden mehr als sie nutzen. aber da ist plan.at keine Ausnahme Die Nachbarbezirke haben eine dünnere Userbasis, und es wird wohl noch zig Jahre dauern. Ich hab ja sowieso die Befürchtung, dass viele der nichtexistenten Wege (Mauern, Bäche, Geländekanten u.a., die als residentials oder tracks auftauchen) nie mehr verschwinden werden. Im Zweifelsfall einfach löschen. Bei einem Import muss man nicht lange überlegen. Und sogar Wolfgang hat das immer wieder betont. Und ich habe von vielen Leuten gehört, dass es ihnen seit dem Import keinen Spass mehr macht, und sie sich ein anderes Hobby gesucht haben. schade eigentlich. Einfach plan.at Daten löschen und besser machen. Ich verstehe manchmal nicht warum da jemand Hemmungen hat. Daher nochmals die Bitte **freundlich** um die original sourcen betteln. egal welches Format. egal wie falsch sie sind. Ja, bitte kommt in Massen und bringt Bereitschaft zur Diplomatie mit! Ich fürchte, ich selbst bin zu verbittert, um freundlich zu bleiben. Die faulen Eier werde ich gnadenhalber zu Hause lassen ;-) wäre halt super wenn er die Rohdaten bereitstellen könnte oder einen dump der DB. Irgendwer kann dann sicher was damit anfangen. Bei den Strassen ist es ja noch einfach das neu zu machen aber bei Flüssen, landuse … sieht es sehr schlecht aus weil nur die Städte brauchbare Luftbilder haben. LG Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vorankündigung: OSM am OpenSourceDay (28. Mai in Innsbruck)
Das waere doch endlich einmal die Gelegenheit Wolfgang freundlich! zu bitten die source Daten von plan.at der community zur Verfuegung zu stellen. Ich kann gut verstehen dass er zu dem Thema keine Kommentare mehr in diesem Forum gegeben hat. Die Kritik war teilweise schon ungerechtfertigt und er hat jeden upload mit der Bemerkung zum loeschen freigegeben. Bearbeitung war explizit erwuenscht und das haben wohl einige nicht gelesen oder nicht verstanden die erst spaeter eingestiegen sind. Massen importe sind immer problematisch und fast alle sind gleich schlecht oder noch viel schlechter gelaufen. Ein import sollte immer nur osm files generieren und die community kann das dann lokal verifizieren und Stueck fuer Stueck einbauen. Daher nochmals die Bitte freundlich um die original sourcen betteln. egal welches Format. egal wie falsch sie sind. oft hilft es schon weiter wenn wir die namen bekommen oder einen WMS layer haben. besser als viele andere Daten ist das allemal. Automatisch kann man inzwischen eh nichts mehr einpflegen. Da muss schon jmand genau ueberlegen was passt und was nicht. 2010/5/11 Boris Cornet bor...@osm-at.org Hallo! Das darf man sich nicht entgehen lassen: open source day 2010 28. Mai 2010 ab 13:30 Uhr in der Wirtschaftskammer Tirol, Meinhardstraße 14, 6020 Innsbruck Das Programm: http://opensourceday.at Es gibt einen einstündigen Vortrag über OSM von - und jetzt bitte festhalten - Wolfgang W. Wasserburger, der dort offensichtlich Werbung für seine bekannte Anwendung plan.at zu machen gedenkt. Lasst uns ihm einen herzlichen Empfang bereiten, kommt bitte massenhaft! -- Mit freundlichen Grüßen, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Path/Cycleway/Footway/Track
this is an old topic on talk and never a final agreement. changing the wiki might create big discussions I agree with your definition and use it the same way. On Fri, May 7, 2010 at 12:50 PM, Val Kartchner val...@gmail.com wrote: The descriptions on the wiki are quite ambiguous as to when to use path, track, cycleway, footway or bridleway. There aren't any places around here that I've tagged as bridleway, so I'll leave that one alone for now. Otherwise, here is the criteria that I have been using: Path: Unpaved, narrow way in the foothills or mountains. Track: Unpaved, way wide enough for a vehicle. Cycleway: Paved, usually urban and asphault, way designated for use by bicycles. Footway: Paved, usually concrete, way designated primarily for use by pedestrians. Are these good definitions? If so, let's modify the wiki to be unambiguous. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Months-old vandalism needs to be taken care of
these tools can't help here because data has been changed already by other users. trying to revert partial changesets can do more harm. 2010/5/4 Niklas Cholmkvist towards...@gmail.com Hi, Maybe a read in osmtools? I also just discovered that page. It even provides instructions on what one can install on one's system to make the software run. libwww-perl. Does one maybe need a configured webserver for it to run? From what I read on wikipedia of [[Library_for_WWW_in_Perl]] maybe one isn't required. http://svn.openstreetmap.org/applications/utils/revert/README Maybe setting the software in motion is more difficult than I think. Regards, Niklas -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] [Tagging] Fast food vs. restaurant vs. cafe
On 3 May 2010, at 5:18 , Greg Troxel wrote: Katie Filbert filbe...@gmail.com writes: * Baskin Robbins (fast food?) This is the missing ice cream shop I think. But if they serve other food, it's made to order, and they have table service - restaurant. * Fuddruckers (restaurant or fast food?) tough call * Panera Bread (restaurant or cafe?) cafe - food is made to order, and while fast, it's real food. Basically my rules are: restaurant: full menu, table service, can walk in for dinner or lunch and get a proper meal fast food: pre-made hamburgers etc. with counter ordering. tends to be not 'real food' from the foodie-nut point of view. definitely burger king etc. is this category. I also put dunkin donuts in this category. cafe: place to get coffee and light food, typically no table service, but limited menu. (You may ask: what's the difference between cafe and fast food? 1) cafe has 'real food' vs chemically engineered pseudofood. 2) cafe tends to be a nice place to go vs a place to go when you don't have time to eat and are desparate. That has lots of bias, but it's an important distinction. I'd put starbucks here, just barely. independent coffee shops almost certainly. ice cream stand - this is tough, and it's sort of like a cafe that has ice cream instead. I try to think: what will map users want to know. This is all heading down the slippery slope of a full ontology for the world and also encoding judgement. My bias is clear: a cafe is a nice place to go, fast food is to be avoided. good summary. and because of the rule fast food to be avoided I rarely map these. and interestingly I see more real restaurants and cafe in osm. are most mappers foodies? ___ Tagging mailing list tagg...@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin boundaries tied to roads
On 23 Apr 2010, at 19:46 , Alan Mintz wrote: At 2010-04-23 07:47, Apollinaris Schoell wrote: I don't know about completely. The parts of the Kern/LA/Orange/San Bernardino/Riverside/San Diego borders that I have surveyed are at least close to the signage at important points (admittedly a weak standard), but I've also gone hunting for detail in law in some spots and found that the borders were right as of their date of creation in the source data. I remember manually fixing a little bit of the OC/LA border in La Habra from some sort of change description - maybe something out the BAS project. What a pain that was. depends on the definition, for me a difference of 100-200m is too bad. any GPS or verbal description is better if matched with Yahoo. In some corners even worse complex edges have been entirely clipped. USGS is pretty good and matches county borders. County borders are from official state data and are high accuracy. Also Sat matches well when borders follow natural features. USGS tracing is very difficult because borders are often hard to identify among other features. Is anyone working on borders currently? Is the BAS a reasonable source? what is BAS? any better source will be useful -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Updates for JOSM
On Wed, Apr 21, 2010 at 3:11 PM, Sebastian Klein basti...@googlemail.comwrote: yes this is important. don't tag nodes if they have no other tags. will just increase the DB size with no value. imports did this and bots have cleaned up so good to stick with it Btw. you can add a source tag to your changeset in the upload dialog. But that's more for the record, other users won't see it in the future unless they query the changeset. much better for a simple reason. anyone can delete the source tag form an object. having it on the changeset is as visible as having it on the object itself. only history of object will show it. And think about it is it still the same source if user A uploads a gpx and user B des adjustments with Yahoo, user C adjusts based on topo map ... adding a chain of source isn't useful at all Sebastian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Updates for JOSM
On Wed, Apr 21, 2010 at 4:11 PM, John Smith deltafoxtrot...@gmail.comwrote: On 22 April 2010 08:41, Apollinaris Schoell ascho...@gmail.com wrote: much better for a simple reason. anyone can delete the source tag form an object. having it on the changeset is as visible as having it on the object itself. only history of object will show it. And think about it is it still the same source if user A uploads a gpx and user B des adjustments with Yahoo, user C adjusts based on topo map ... adding a chain of source isn't useful at all you can't delete the source tag from historical versions, only the current version, the source should reflect the last used source of information. that's what I have written ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Josm Hausnummernanzeige auf OSX
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Mac_OS_X wichtig ist dass webkit-image irgendwo installiert wird dass es im Suchpfad gefunden wird. On 16 Apr 2010, at 6:55 , UMAX974 wrote: Ja ich weiß, es gibt Menschen bei denen läuft WMS am Mac, bei anderen nicht so richtig erklären konnte es mir bisher keiner, damit ich das dann auch hinbekommen hätte UMAX974 Am 16.04.2010 um 15:38 schrieb Gehling Marc: Tach, au man. Es war die Drahtdarstellung. Jetzt alles prima. Am 16.04.2010 um 14:35 schrieb UMAX974: Das einzige wirkliche Problem zu dem ich bisher mit JOSM am Mac keine Lösung gefunden habe ist die WMS Darstellung, das hab ich bisher weder unter os 10.4 noch unter Os 10.6 zum laufen bekommen. der WMS läuft bei mir. Leider nicht reproduzierbar. Woran ich gerade arbeite ist tilecache und mapproxy. wollen beide nicht so richtig. Marc ___ 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
Re: [Talk-de] Josm Hausnummernanzeige auf OSX
besser nicht nach /usr/bin weil da fliegt das nach einem upgrade raus. sondern z.b. nach /usr/local bin oder in einem lokalen pfad. ist halt nicht fuer reine Gui user 2010/4/16 Werner Beckmann werner.beckm...@googlemail.com Ganz schlaue Antwort meinerseits: bei mir gehts... http://wiki.openstreetmap.org/wiki/User:WernerBeckmann Hast du das probiert mit QT und dem Verschieben nach /usr/bin (webkit-image meine ich)? Habe es so auf einem iMac und einem MacBook Pro (10.6 beidesmal) zum Laufen bekommen. Kann natürlich auch Zufall sein oder von der Apple-Dev-tools-Installation abhängen... Gruß, Werner Am 16.04.10 16:52, schrieb Apollinaris Schoell: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Mac_OS_X wichtig ist dass webkit-image irgendwo installiert wird dass es im Suchpfad gefunden wird. On 16 Apr 2010, at 6:55 , UMAX974 wrote: Ja ich weiß, es gibt Menschen bei denen läuft WMS am Mac, bei anderen nicht so richtig erklären konnte es mir bisher keiner, damit ich das dann auch hinbekommen hätte UMAX974 Am 16.04.2010 um 15:38 schrieb Gehling Marc: Tach, au man. Es war die Drahtdarstellung. Jetzt alles prima. Am 16.04.2010 um 14:35 schrieb UMAX974: Das einzige wirkliche Problem zu dem ich bisher mit JOSM am Mac keine Lösung gefunden habe ist die WMS Darstellung, das hab ich bisher weder unter os 10.4 noch unter Os 10.6 zum laufen bekommen. der WMS läuft bei mir. Leider nicht reproduzierbar. Woran ich gerade arbeite ist tilecache und mapproxy. wollen beide nicht so richtig. Marc ___ 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 mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Google's Park Outlines?
It simply depends where they got their data from. many GIS sources are available and free to use but accuracy is another thing. even some official county data can be off. have seen also big errors in the official state park data which doesn't match what is on ground and also clearly seen on yahoo aerial pics. Also most national park data is outdated and of bad quality. There are better sources available but they are not free. google relies on automatic processing and osm strength is to have many doing survey on the ground. On 14 Apr 2010, at 5:39 , Jeffrey Ollie wrote: Has anyone noticed that the park outlines in Google maps has been changing? They will either shrink and not cover parts of the park that it did before or they will expand and cover areas that are not part of the park. As an example: http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=-93.58291lat=41.73747zoom=15 Heritage Park should be on both sides of the creek. Michael park has been moved completely, it is actually a small neighborhood park at the corner of NE 7th St and NE Wanda Dr. The outlines for Crestbruck Park and Sunrise Park are fairly accurate. I guess this is a win for Open Street Map but a lose for people that use Google Maps to get places. Is this just fallout from Google's switch away from commercial map data providers? -- Jeff Ollie ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Reversion of Edits
can you send a list of changesets? please add also the communication with the user to have it documented or add a wiki page with the info On Tue, Apr 13, 2010 at 1:41 PM, Vitor George vitor.geo...@gmail.comwrote: Anyone can help me with the reversion or we leave as is? Vitor On Tue, Apr 13, 2010 at 3:31 PM, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: I'll leave that for whoever decides to do the revert. I don't do reverts. Shaun On 13 Apr 2010, at 19:58, Vitor George wrote: Shaun, Do you need more information about this case? Thanks, Vitor On Sat, Apr 10, 2010 at 7:55 PM, Vitor George vitor.geo...@gmail.comwrote: He confirmed that he was copying from a copyrighted source, and said ok for the revesion. I´ve explained that he coulnd´t do this copy and sent him a wiki link about legal sources of information. Vitor 2010/4/9, Shaun McDonald sh...@shaunmcdonald.me.uk: On 9 Apr 2010, at 17:43, Vitor George wrote: Hi there, There is a user in Brazil that is copying street names and other things from copyrighted maps. We've already talked to him. Can you please elaborate on your contact with the user? What has been said? Is he happy for the revert? Shaun http://www.openstreetmap.org/user/andredrm He's a new user, so I think we can reverted all of its edits. How can we do this? Vitor ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Enviado do meu celular ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] Accidental deletions in Victoria
I can revert it if the data hasn't been changed and you didn't do other edits in the same changeset. check the changeset and if you think it should be reverted as a whole let me know. If you prefer to revert just some portion it's best to use Potlatch and with key 'U' you will see all deleted data in red. after clicking the unlock button the way is back and can be edited as usual. On 8 Apr 2010, at 7:58 , Peter Freeman wrote: I was the person that deleted Dallas Road. I would like to know how it happened, however I am thinking that it might have been caused by Validator when I used the Automatic Fix of nodes without ways. I can repair it as I have a number of GPS traces of the road from various bike training rides over the last year, however, I would like to know how to revert the changeset. In future, I will keep an eye on what Valiadator does. Does anyone have any experience with Validator issues? Thanks, Peter On Tue, 2010-04-06 at 17:37 -0700, Gregory wrote: Ah, I was editing around the area (LivingWithDragons) and saw all the nodes with no ways, I thought my computer was just having trouble loading them (I'm not very familiar with Potlatch). As a note, there are a couple of areas inside the park that are ponds traced from Yahoo but not yet tagged, I was planning to deal with them when I add some footpaths using JOSM. I made a day trip to Victoria on Saturday. Does anyone on the talk-ca list know how to deal with reverting data? I think there is some helpful revert feature in Potlatch, but I don't know how to use it. On 6 April 2010 17:16, Corey Burger corey.bur...@gmail.com wrote: I have noticed three accidental deletions in the Victoria area recently: Ring Road entrance, Thompson Rd in Oak Bay and most recently, Dallas Road. I have sent a message to the user but somebody needs to get in and revert the change. You can see the damage here: http://www.openstreetmap.org/browse/way/4676365/history Corey ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Street Naming Conventions
On 8 Apr 2010, at 9:42 , am12 wrote: Some of the examples comma separated into the 4 field format: South, ,1000 East, Street Paul Johnson mentioned on IRC today the case of East Doctor Martin Luther King, Junior Boulevard, which wouldn't work with this schema I don't think *storing* them as comma separated was the suggested scheme; it was just data samples in the email. Storing them could/would be done as 4 fields, like TIGER. In which case this street name works just fine. I think the tag like name= should really be consistent so tools can rely on it without adapting to every single country. Definitely. If implemented, the 4-field breakdown should be in addition to the name= field. As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Sure. I think the suggestion was really just to take that structure and make it available/standard for all streets, not just tiger imports in the tiger namespace. So the example above would be directional_prefix=East base_name=Doctor Martin Luther King, Junior name_type=Boulevard directional_suffix= name=East Doctor Martin Luther King, Junior Boulevard Is it redundant? Mostly. Is it maximally informative and flexible? Yes. I wonder if all areas that use a directional suffix put them after the name type (Maple Street SouthEast), or if some put them before the name type (Maple SouthEast Street)? In which case, the full name is not actually redundant but holds proper ordering info not in the separated fields. my experience is that directional is a prefix not a suffix as this discussion shows there is no definitive rule and the only way this could be done is to have full name on the name tag and and name:abbrev tag with the abbreviation used locally. your tagging scheme is well meant but might be overly complicated to use. I think converting existing names with a bot to name=fullname name:abbrev=abbrev name is quite safe. as alternative it wouldn't be bad to keep the current abbrev names on the main tag because all geocoders use them instead the full name. and use this instead name:nonabbrev=fullname name=abbrev name advatage is that rendering doesn't need to change and will use same stryle as all existing commercial maps. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] PA State Parks
On 24 Mar 2010, at 18:47 , Tyler Ritchie wrote: On Wed, Mar 24, 2010 at 5:46 PM, Sven Lafebre s.lafe...@psu.edu wrote: Hi all, I've been looking at state parks, state forests and state game lands in Pennsylvania. I think Adam Killian uploaded most of these a year or two ago—I don't know if he's on this mailing list. Most of these parks are tagged as physical areas. For example, state game lands are natural=wood and leisure=nature_reserve. Unfortunately, these tags don't always correspond to the actual land use. Moreover, they are really administrative entities, not physical ones. So I would like to change them to something similar to the scheme used for parks e.g. in the Bay Area: boundary=national_park admin_level=4 park:type=state_game_land The underlying physical land use can then be mapped orthogonally to this. Are there any objections to this? Am I forgetting anything? Please let me know! I'd probably toss in some ownership tag as well. definitely if it makes sense, in this case state_game_land is a clear sign for the ownership in some areas parks or openspace is privately owned and such info is valuable ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] [Talk-us] Going to Where 2.0 and Want to Work the Booth?
Hi Kate, Will be in the area but can't make time during the day. Any plans for evening events? Apollinaris On 19 Mar 2010, at 15:32 , Kate Chapman wrote: Hey All, Are you attending Where 2.0 and want to work the booth? I put up a wiki page for people to sign up for slots. http://wiki.openstreetmap.org/wiki/Where2.0/2010 Thanks, Kate ___ Talk-us mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Going to Where 2.0 and Want to Work the Booth?
Hi Kate, Will be in the area but can't make time during the day. Any plans for evening events? Apollinaris On 19 Mar 2010, at 15:32 , Kate Chapman wrote: Hey All, Are you attending Where 2.0 and want to work the booth? I put up a wiki page for people to sign up for slots. http://wiki.openstreetmap.org/wiki/Where2.0/2010 Thanks, Kate ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
