Partial Revert of boundary nodes in (116209290), see 93359799 comment

Partial Revert of boundary nodes in (116209290), see 93359799 comment

Partial Revert of boundary nodes in (116209290), see 93359799 comment

Partial Revert of boundary nodes in (116209290), see 93359799 comment

Partial Revert of boundary nodes in (116209290), see 93359799 comment

Hello,

I've reverted some of the changes you made to the boundary nodes here, which affects the shape of the suburb. try to avoid touching the boundary nodes if you can in future :) (116209290)

No worries :)

I certainly don't feel as though it is causing any harm by adding this data to nodes, and I wouldn't advocate for someone to actively remove the data that has already been added. I reached out because I saw you were potentially about to embark on a large piece of work with the challengre - I know how it feels to work on a big project only to find it's less important than I first thought. My free time is limited these days, and my fear of opportunity costs is real :)

Definitely agree with you that there could be some clarity on the Australian Guidelines. I'm not sure if you are already on the talk-au mailing list (https://lists.openstreetmap.org/listinfo/talk-au) but I've found it to be relatively active and everyone I've encountered has been helpful and encouraging.

I'm happy to give a very basic explanation; obviously every piece of software/implementation will be different and I am in no way an expert. :)

The default OSM map using Nominatim (osm.wiki/Nominatim) to convert search queries to actual locations. The way it works is pretty neat: https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=9242317546&class=place

If the postcode is attached to the suburb relation (which, in Noble Park's case, it isn't), it can pull the data from there, otherwise it does rely on some "magic" by looking at places nearby. The quickest way to attach a postcode to all these houses would be to add it to the suburb relation, which will allow the postcode to flow through with the suburb (https://nominatim.openstreetmap.org/ui/details.html?osmtype=N&osmid=6150731669&class=building)

For other programs and services, determining which boundaries apply to a particular point is a fairly standard function of GIS software. I can appreciate your concern about computational load, though I would suggest that the extra storage space required for the postcodes on each node would outweigh any marginal benefit.

Hey :)

Just wondering what the utility of this tagging is?

The postcode and state could already be determined by looking at the administrative boundaries?
---

Published using OSMCha: https://osmcha.org/changesets/116045298

Gday MapMeister!

Thanks for your contribution. :)

This laneway appears to be mapped pretty well, but I'd recommend one or two minor adjustments.

The name of the laneway appears to be a descriptive name of what it used to be, rather than the signposted, official name. It's ok to leave a road without a name tag, and instead use the description tag to provide more information.

I'd also suggest this is better suited as a alley, rather than an unclassified road. (Or maybe a footway, if it's too narrow?) The alley tag is pretty much an equivalent of what we would call a laneway in australian english.

Keep up the good work :)
---

Published using OSMCha: https://osmcha.org/changesets/116007596

G'day!

Thanks for your work in and around Carnegie :).

Just quickly, I noticed that you renamed the Australia Post shop to "Vacant (leased)". That's really useful information, but we generally try and keep the name of a shop to be the literal name, rather than a description. (ie: Bob's Milk Bar vs "Milk Bar"). In this case, it's okay to just remove the name and leave it blank.

If you haven't already, it'd be great to see you on the talk-au mailing list. :) https://lists.openstreetmap.org/listinfo/talk-au

Dian
---

Published using OSMCha: https://osmcha.org/changesets/115876326

Hey Ben,

Thanks for the contributions. :)

A couple of points I wanted to raise:

You've added the name of the property to the driveways at way/1016437084 and 23895153. The name of the driveway isn't literally the name of the address osm.wiki/Names#Names_are_not_for_descriptions. These are better placed in the description tags.
On a related note, you don't need to include the state, postal code and suburb in the address fields of each address; those are inherited by the boundaries that are already defined. :)

In this edit, you've attached some land use nodes to the highways using the same nodes. While that's not necessary wrong, it can make things much harder to keep up to date if the road geometry changes. The wiki explains the contract pretty well: osm.wiki/Land_use#1._Mapping_the_reality_on_the_ground. The fence lines in the area are well defined enough to make it possible to adjust the land use areas to the actual boundaries.

I've made some changes in line with what I said above, but please don't be offended. If you aren't already, it would be great to see you on the mailing list: https://lists.openstreetmap.org/listinfo/talk-au.

Happy mapping .:)

Hello,

I'm changing Hangar Lane back to type alley as I believe that it best describes the nature of the highway, and because driveway2 is a deprecated tag without usage in Australia.
---

Published using OSMCha: https://osmcha.org/changesets/115461885

No worries, cheers mate. :)

I know was you mean about the rabbit hole! I created an account to make just a single edit…

Hey Mapillary,

The population and Wikipedia link for Croydon is already on the relation. I think doubling up with details on the node is unnecessary?
---

Published using OSMCha: https://osmcha.org/changesets/115027321

Hi,

You've added elements and altered geometry based on aerial imagery, but the edits are not correct.

The bend on Lakeside drive, and the realignment of Ross Gregory Drive have been completed since the imagery was taken. You can see the details of the change on the Grand Prix website

I have changed those back now.
---

Published using OSMCha: https://osmcha.org/changesets/113477031

I certainly won't argue with you regarding the congestion at the intersection! :)

I can appreciate that drivers approaching this intersection would need advance warning to be in the left-most lane. It's always busy at this intersection, but if you are trying to warn a driver to stay left, even where you've moved the node wouldn't be early enough; they really need to be in the left lane well before Olympic Boulevard!

I happened to raise this issue on the talk-au mailing list and was told that this method of moving the "split" node earlier was a common way of modelling intersections some time ago to achieve the "early turn warning", but newer tags such as destination, turn, change, etc are being used by routing software to give better directions, rather than us mappers trying to estimate where is most appropriate.

You can see the tags I've placed on Punt Road northbound (976172874) include lane-specific destinations, so that lane assistance within routing software should be able to tell well in advance which lane the driver should be in. :)

Thank you for the reply.

I understand your reasoning behind relocating the split, but I believe you have misapplied some of the logic from the wiki's you've quoted.

I'm referring to the Editing Standards and Conventions wiki page: osm.wiki/Editing_Standards_and_Conventions#Divided_highways.

"A divided highway is any highway were traffic flows are physically separated by a barrier."

A solid white line is not enough to justify splitting the way: if it were then logically you could separate every lane where lane changes are prohibited. This legal separation is best represented with the change: key.

In regards to traffic lights, we are both aligned with the understanding that traffic lights do not represent the physical location of the lights. My objection to this modelling is because there is a single contiguous stop line for all lanes heading north, and both set of lights have both the turn arrows and green light. Even though the pedestrian crossing is further into the intersection, the traffic light for the left turn seems no different than a separate turn signal to turn right, which is modelled with a single node.

Lastly, I feel the use of the motorway_junction is inappropriate. Punt Road is not a motorway, and this turnoff is not a numbered or names junction that would justify usage of the tag. Again, we don't use junctions on every slip lane. There does seem to be some contradiction between motorway_junction and the rest of the wiki; it doesn't seem to have been updated as heavily as other pages. Notwithstanding the status of the wiki page, the hatched areas in motorways are significantly wider than this example; probably wide enough to arguably be "physically separated". The having here is maybe, a metre or so? I don't believe that's enough to justify a "motorway_junction" node.

I'm happy to discuss further. I'm aware this is comparatively minor and may seem like quibbling, but a lot of the network analysis tasks that use OSM data rely on consistent modelling that distinguishes between "legal" and "physical" separation.

Hey MapAbility.

I’m not sure I understand the reason for your change.

You have moved the point where left turn to Brunton splits further south, and then added another traffic light node?

There is only one set of traffic lights for that direction of travel, and it is before the traffic island.

Further, by moving the split point on Brunton further west, you’ve made the lanes tag much less accurate.

What was wrong with the previous modelling?
---

Published using OSMCha: https://osmcha.org/changesets/114697556

Thanks; appreciate the response.

I've been moving them to the relations when converting the nodes to label, rather than deleting them out of an abundance of caution. I'll continue the practice :)

Appreciate your contributions!