ตราสัญลักษณ์ OpenStreetMap OpenStreetMap

Changeset เมื่อ แสดงความเห็น
93499763 กว่า 4 ปีที่แล้ว

Hi and thanks for getting in touch. Unfortunately my Polish is nonexistent, so I will just reply here. Feel free to distribute as you wish!
I am mostly focusing on roads with an extra letter suffix, i.e. sections numbered independently from the rest.
My main source of information are the traffic reports at https://www.gddkia.gov.pl/dane/zima_html/utrdane.xml (linked from dane.gov.pl, search for “utrudniena na drogach”, open data as per the web site). They have the road ref as well as the start kmp and length, which allows us to infer the minimal length of that particular segment (highest sum of start kmp + length ever observed). There is also usually a coordinate pair near the start, but that can be several hundreds of meters off.
I usually check if that is consistent with already-mapped milestones. So, if near the position for S42x km0 I see a milestone with distance=0, ref=S42, I know the stretch starting there is S42x, and I add the ref to the milestines—until the highest sum of start kmp + length I have seen so far, or for as long as the numbering is contiguous, or until the end of the section which was completed at the same time.
If there are no milestones, I check Mapillary or OpenStreetCam for footage and map the milestones.
The S5k is a particular case, as there is no footage, so I had to approximate the milestones (the only time I did this so far): kmp 0 is near Mosina, at the end of S5e (for which the highest observed kmp is 17.480, close to the position reported for S5k, km 0). There were milestones but the numbering was just a continuation of S5e, so I left the milestones and subtracted 17.5 km from the distance. The highest kmp I observed on S5k is 34.619, which would then be around Lipno, where S5f starts (not at km 0, though: kilometric points seem to be a continuation of S5e, starting around km 52).
There’s still a potentially large error in this particular case (I got three positions for different kmps from GDDKiA, and they disagree by as much as one km), but better than what we had before and sufficient for me to process traffic reports at “S5k, km 0 to 18.900” to an approximate coordinate pair. Of course, if someone can survey this stretch and either correct the milestones or upload imagery to Mapillary, that would be even better.
If anybody happens to have a list of “suffixed” road refs (with a trailing letter) which we can officially use for OSM, that would be even better; even if it just covers a part of Poland. I have suggested this to dane.gov.pl as a new data set (GDDKiA should have that data; I know for a fact they have it at least for some voivodeships, they would just need to release it under a free and open license); we’ll see what comes out of it.

71284045 เมื่อ 6 ปีที่แล้ว

I see the wiki page osm.wiki/Tag:highway%3Dmilestone was recently updated with content which was not there at the time of this changeset.

My use case is that I am trying to make sense of locations such as “km 36 on DK3”, commonly used by road administrations. For this I would need an easy way to identify all milestones along DK3, pick the one with the desired distance, and determine its position.

On dual-carriageway roads, common practice seems to be to place milestones between the two carriageways, not connected to either. Without a tag indicating the road to which the milestone belongs, establishing the link becomes very complex.

Looking the existing data in Poland, there are 35,000+ milestones. Almost all of them have a ref=* tag pointing to the road (which includes my own edits, 97 nodes in total); only 87 nodes have no ref tag set.

One can argue whether ref=* is the correct tag to use for that, as it is the reference number of the road, not of the milestone. I have put this out for discussion at osm.wiki/Talk:Tag:highway%3Dmilestone#Use_of_.7B.7Btag.7Cref.7D.7D.

17125269 กว่า 6 ปีที่แล้ว

Re ventilation shafts, I just stumbled across these two links:

http://www.standseilbahnen.ch/san-bernardino-aria.html
http://www.standseilbahnen.ch/san-bernardino-sasso.html

Neither ventilation shaft is perfectly vertical. Aria has an inclination of 309.79% and an elevation difference of 354 m. That means the overground structure could be up to 115 m away from the carriageway (less if the shaft is not perpendicular to the carriageway). Sasso has an elevation difference of 318 m and an inclined length of 490 m, which places it within some 370 m of the carriageway. We are well within these limits. In fact I might have slightly overdrawn the curvature of the tunnel, as JOSM tells me it is 6.7 km long when its actual length is 3,596 m.

17125269 กว่า 6 ปีที่แล้ว

OK, just pulled out my video and tried to approximate distances by marker lights (which seem to be some 20 m apart) and odometer readings. There’s still considerable inaccuracy, as the odometer has a resolution of 100 m and some marker lights are missing. In any case, I assumed all turns (there are four throughout the tunnel, two of them right at the portals) to have equal radii, which would make the bearing change directly proportional to the length of the turn. With this I approximated the bearings of the straight segments. The first quarter seems to be quite accurate, as the tunnel gets quite close to the Aria structure. The Sasso structure is still some 200 m away from the calculated position of the tunnel, but the ventilation shaft is not necessarily vertical.

osm.org/changeset/68277209

17125269 กว่า 6 ปีที่แล้ว

Either that or get the tunnel closer to the phone and ventilation shafts. I have a dash cam video of a trip through the tunnel, and a photo sequence of another (in the opposite direction). I have mapped the Fréjus tunnel in this manner, using the marker lights on the kerb to estimate distances as well as curve radii (based on the number of lights visible before those on the outside disappear behind the inside wall).

17125269 กว่า 6 ปีที่แล้ว

Hi dikkeknodel,
It’s been a while, therefore it’s hard for me to tell how things looked right after this changeset. Chances are the tunnel was moved afterwards (maybe even by myself) and the phone forgotten.
The main issue is that we don’t have the exact course of the tunnel, it is possible that the tunnel extends further west than currently mapped. The turns were approximated from surveys but may be much sharper. There are two ventilation shafts (I believe that’s what they are, named Aria and Sasso) with overground structures right next to the pass road, currently some 200–300 m west of the tunnel. The tunnel has two niches with these names, which indicates they are right underneath the underground structure. (Though that does not necessarily have to be the case, I know for a fact that the Fréjus tunnel has a ventilation shaft where the overground structure is a few hundred meters from the tunnel.) Bottom line: we need a better estimate of the course of the tunnel.
stanton

58737525 เกือบ 7 ปีที่แล้ว

Hallo PT-53,
leider gibt es aktuell keine befriedigende Lösung, Langzeitbaustellen zu taggen.

* highway=construction bezeichnet Neubauten und ist in Fällen wie diesem (vorher war dort eine Straße, die hinterher mit exakt dem gleichen Verlauf wieder hergestellt wird) m.E. schlicht falsch.
* access:*=no macht aus meiner Sicht mehr Sinn, hat aber den gleichen Nachteil, dass nirgends ersichtlich ist, wie lange dieser Zustand andauert.

Ich stimme dir zu, dass solche Baustellen von allen Routern berücksichtigt werden müssen. Ebenso muss aber die Straße wieder als benutzbar erkennt werden, wenn die Bauarbeiten vorbei sind—auch von Routern, die Offline-Material verwenden, das nicht unbedingt tagesaktuell ist (weil niemandem zugemutet werden kann, sich jede Woche die komplette Europakarte neu aufs Handy zu laden). Mit highway=construction fehlt jede Information, wie lange der Zustand dauert.

Letztendlich sind beide der obigen Schemen “tagging for the renderer” bzw. “tagging incorrectly to work around a broken application”—und hier ist die Ansage “repariere den Renderer” (bzw. in diesem Fall die Routing Engine). Auf Dauer brauchen wir ein Tagging-Schema, das zeitlich begrenzte Features (“wegen Bauarbeiten gesperrt von… bis…”) unterstützt und von den Routing-Engines verstanden wird.

Wenn du einen Vorschlag hast, wie wir diesen Zustand erreichen können, bin ich für jede Anregung dankbar. Gern können wir das auch im größeren Kreis diskutieren.

Grüße
stanton

47212866 กว่า 8 ปีที่แล้ว

Den Feldweg habe ich vor Ort überprüft, dort steht tatsächlich ein entsprechendes Schild—sowohl am Zellerhof als auch am südöstlichen Ende von osm.org/way/403520482. Habe schon von beiden Seiten versucht, zum Zellerseeweg zu kommen, und bim am Verbotsschild gestanden.

Den Steg (wenn das einer ist) habe ich vor Ort nicht überprüft—war schon vorher als Teil der Kontur des Sees gemappt, ich habe lediglich die Konturen korrigiert. Das wäre vor Ort zu überprüfen—wenn das wirklich nur ein Steg (mit Wasser drunter) ist, wäre eine Fläche innerhalb des Sees mit man_made=pier korrekt. Wenn das aber eine Betonstruktur ist, die bis auf den Seegrund geht, sieht die Sache anders aus—dieser Teil des Sees ist (war?) ein bewirtschaftetes Freibad, wo offensichtlich einige Eingriffe in die Uferlandschaft stattgefunden haben. Klarheit bring nur eine Überprüfung vor Ort—ich mache eine Note auf.

35715911 กว่า 9 ปีที่แล้ว

Hi OSM-helmut,

It seems you've introduced a few errors in this changeset:

First, you have moved node 3666402313 (near Luise-Kiesselbach-Platz) and made it part of a surface road. The node, however, represents a speed camera in the tunnel (as is clearly visible in the tags), therefore incorporating it into a surface road is clearly a mistake.

Furthermore, you seem to have created copies of this node (with the full set of tags) and made them part of the surface road as well.

I have now created a copy of the original speed cam node, moved the copy to the original position of the node and made it part of the enforcement relation, removing the old node from the relation. Furthermore, I have removed all tags from the three nodes you added to the surface road.

I might have missed something, thus I would ask you to take another look at this changeset to see if you've unintentionally introduced other errors.

stanton