OpenStreetMap logo OpenStreetMap

Changeset When Comment
65667259 about 6 years ago

Hello pfg21,

It looks like you changed some roads (osm.org/way/319392168, osm.org/way/613474896, osm.org/way/613474898, and osm.org/way/613474900) to standard highways instead of highway_link when they serve to access M-7. Per OSM policy (osm.wiki/Highway_link) link classification should be used. Thanks!

65118528 about 6 years ago

Hello pfg21,

I am curious why these ways (osm.org/way/150397582 and osm.org/way/377084451) were reclassified as trunks, when they are meant for U-turns, and not the majority of traffic.

66378246 about 6 years ago

Hi Юлия2605.

It appears that the route P-215 is currently modeled as a relation about 50 miles to the northwest of where you added the new ref tag in osm.org/changeset/66378246, osm.org/changeset/66404575, and osm.org/changeset/66405885.

In addition, the routes E119 (osm.org/relation/1789104) and AH8 (osm.org/relation/3745454) currently travel from the northwest to the south of this location. Based on OSM global policy, “ref_1” and “ref_2” do not appear to be approved tags.

These routes are generally tagged as int_ref=* as stated on the OpenStreetMap Wiki page osm.wiki/Key:int_ref.

Do you have any resources to confirm that these 3 routes extend along the primary road where you added them in the above changesets? Thanks!

64363390 about 6 years ago

Hello Dinamik!

I noticed a lot of link classifications were change to non-link classifications, such as here: osm.org/way/131523100, and here: osm.org/way/131528505, but per OSM policy (osm.wiki/Highway_link) link classification should be used for ramps like this in order for routing engines to give proper instructions. I am curious why these changes were done. Thanks in advance for your response.

66204783 over 6 years ago

Sounds good. It may be good to reach out to JOSM contributors to make them aware of this issue and also potentially to Nominatim to add missing search variables. Is that something you would want to do? If not, I am happy to reach out as well! This would solve potential issues going forward. I’ll make the change back to your suggested method. Thanks!

66204783 over 6 years ago

Hey JaLooNz,

Looks like building:part=residential was added to osm.org/way/408163451, osm.org/way/440538815, osm.org/way/440538818 due to JOSM validation error (building within building). The wiki (osm.wiki/Simple_3D_buildings#Building_parts) appears to support this change but you mentioned building:part with address is not searchable in Nominatim. It appears that one method breaks nominate (building:part=residential) and the other method breaks JOSM validator. (building:part=yes + building=residential). Thoughts on how to proceed here?

Thanks

68107232 over 6 years ago

@Hjart - you mentioned that the Ålborg airport has a similar issue. It looks like mikkolukas and juliaboy agreed to having one polygon with both a military=airfield and a aeroway=aerdrome tag. This also follows OSM policy: osm.wiki/Tag:aeroway%3Daerodrome#Military_airfields. Is this something that could be considered here? Or like you mentioned earlier, "2 separate (but possibly overlapping) areas?"

68107232 over 6 years ago

jan_olieslagers,

I am also curious about what kind of relation you have in mind. Do you gave an example of one already in the data?

68107232 over 6 years ago

Hello jan_olieslagers,

I noticed that (osm.org/way/666909831#map=17/56.31117/9.12177) does not cover any of the runways or taxiways. Per the OSM wiki (osm.wiki/Aeroways) and various international airports (Way: Flughafen München (487185364), Way: Heathrow (185882029), Way: O'Hare International Airport (25821866)) this polygon would be more appropriate (osm.org/way/485655137) to have the aeroway=aerodrome tag on it.

I have two suggestions.
I can transfer all the tags from Way: 666909831 to Way: 485655137.
I can realign the geometry for Way: 666909831 to cover the runways and taxiways.

What do you think?

Thanks

67140278 over 6 years ago

Hi Kovosch,

While I agree that Yiu Sing Street and Man Yiu Street both serve traffic coming off of the trunk_link, they also serve traffic to and from the other streets in that intersection. Based on this, I think they are better modeled as secondary and tertiary, respectively.

Also, this newly created Discord server (https://discord.gg/5JDE5s) may be a better forum for this discussion!

Thanks

67140278 over 6 years ago

I agree that Man Po Street can also function as a trunk_link. Can you send links to the ways that you are referring to so that I can better understand your second comment?

Thanks

67140278 over 6 years ago

Hi Kovosch,

Per imagery, both 金融街 Finance Street and 民寶街 Man Po Street provide access to 耀星街 Yiu Sing Street. They both also mirror each other with geometry and access to higher priority roads. Also, based on this wiki page (osm.wiki/Highway:International_equivalence), secondary better fits the function of this road.

Thanks

67106898 over 6 years ago

Hi, thanks for the question. We have an agreement with Digital Globe to use some of their recent imagery to edit OpenStreetMap. Where we use it, we always cite the date in the changeset source. We mostly use the imagery that’s already available on iD and JOSM. If you’d like to learn more about the DG imagery, you can browse it here : https://discover.digitalglobe.com

67106898 over 6 years ago

I changed way 666987414 to a service because its purpose seemed to be for providing access to the gas station. I have changed it back. Thanks

65422023 over 6 years ago

Hello nickjohnston, I only split this way to make sure the classifications were consistent, I didn’t want to change any of the ref tags that other users added. Here’s a link that shows what I did: (https://overpass-api.de/achavi/?changeset=65422023).

Thanks

62322945 almost 7 years ago

Thank you.

62322945 almost 7 years ago

Mapillary Image Key: B3aiAnTx95y2JdjCkQ7pHA. Are pedestrians legally permitted to cross where no dedicated crosswalks exist in DNK?

58453624 over 7 years ago

Hello Hjart,

I was also using the public SDFE aerial imagery in Denmark here. Unfortunately, there is no Mapillary in the area but there is a parking lot next to the pedestrian feature I added the tag to here: Way: 583884660.

Thank you,
feta2

58452997 over 7 years ago

Hello Hjart,

I was using the public SDFE aerial imagery in Denmark. There is also Mapillary in this area. Image key: 7ldk-mj6jBBPMuic5f_3NQ Date: 02/18/2018

Thank you,
feta2

57402860 over 7 years ago

Спасибо за полезную информацию. Я буду писать “Ростов-на-Дону” вместо “Ростов-На-Дону