environmental_considerations_and_pseudo_tags.md

[Stapawe]

The file is mainly for users that would like to customise a profile, hence this name

[quaelnix]

I'm pretty happy with most of it, but if the target audience is profile creators, we should probably simplify it a bit.

---

Maybe we should write something like this:

Imagine you trace the way with a pencil drawing lines 100 meters wide. Then estimated_forest_class=6 corresponds to the case that 98% of the line is in the forest.

instead of this:

The green factor is the proportion of a buffered road's area that intersects with a forest area

---

And something like this:

Motorway	Primary	Secondary
105 <= maxspeed < inf	noise_class <= 6	noise_class <= 4	_oise_class <= 3
75 <= maxspeed < 105	noise_class <= 5	noise_class <= 4	noise_class <= 3
0 <= maxspeed < 75	noise_class <= 5	noise_class <= 3	noise_class <= 2

instead of this:

This proportion is reduced:

• for motorways and trunk roads with max speed < 105 by 1.5
• for primary roads 2 times
• 3 times if maxspeed is 75 - 105 for primary and secondary
• other secondary roads 5 times

[Stapawe]

I believe in language simplification and examples and I like what you proposed to add, but I don't think it should lead to decreasing of knowledge of what is going on. I think a profile creator should understand what a buffer is, especially when there is explanation of it. I hope the file could be also useful for developers.

[quaelnix]

Current:

A way parallel to a motorway or trunk road, to have the noise class 6, must be up to 20 m from the middle of the carriageway with a speed limit > 105.

Suggestion:

To be classified as noise class 6, a way segment must be less than 20 m on average from a highway or trunk road with a maximum speed exceeding 105.

---

Regarding the "intersects with" vs. "is inside" terminology. Both the noise class and the river class calculations are based on the overlap between two buffers, see: https://github.com/abrensch/brouter/blob/76265e7713ad203ee6679a810121d2bd22f78074/misc/scripts/mapcreation/brouter.sql#L388-L389 https://github.com/abrensch/brouter/blob/76265e7713ad203ee6679a810121d2bd22f78074/misc/scripts/mapcreation/brouter.sql#L511-L512

Whereas the calculation of the green factor is based on the overlap between the line buffer and the unbuffered forest polygons:

https://github.com/abrensch/brouter/blob/76265e7713ad203ee6679a810121d2bd22f78074/misc/scripts/mapcreation/brouter.sql#L584-L585

So the "is inside" terminology only really applies to the green factor calculation.

[Stapawe]

I've adopted suggestions. I kept the middle of a carriageway as motorways can be very wide

[quaelnix]

https://github.com/abrensch/brouter/blob/master/misc/scripts/mapcreation/brouter.sql

should probably be:

brouter.sql

[Stapawe]

Why? When about half Internet traffic is by mobiles, where the target address is not visible, I prefer longer links, but I can live with shorter ones. If more people don't like it, you can change it if I correctly remember settings.

[quaelnix]

I can also live with the longer one, but the url is incorrect and needs to be fixed. Click the links and you will see the issue.

[Stapawe]

Thanks for spotting, if you are a BRouter maintainer you should be able to edit, that would be quicker.

[Stapawe]

https://github.com/abrensch/brouter/commit/b9ea4eb85a87d61dd24fc505b021dc2125afabad Tagging for render is "using incorrect tags", creating one type of objects that they look like as another type. Dividing a way doesn't add any tags and it doesn't change rendering. I can't see how it would be not a good practice.

[quaelnix]

Tagging for render is "using incorrect tags"

Yes, but this also applies to routing, see the #Generalization paragraph:

The phrase usually refers to renderers, but it may also apply to routing and geocoding and other uses of the data.

---

Dividing a way doesn't add any tags and it doesn't change rendering. I can't see how it would be not a good practice.

It violates the "One feature, one OSM element" principle.

[quaelnix]

Maybe we can phrase it differently in order to express that we do not recommend splitting ways to improve BRouter's pseudo-tag generation, but that in some cases it can make sense to question whether long ways are split in a logically meaningful way?

[Stapawe]

Some examples in "One feature, one OSM element" are about duplication data and some examples could be named "One OSM element, one feature", because they are about situations when elements are more than 1 thing, what is confusing. I think avoiding confusion and duplication is the purpose of this rule. Don't you think a way between junctions could be treated as 1 feature?

[quaelnix]

I'm not against splitting ways when it makes sense, I'm only against recommending to do so in order to fix our 'cheaped out pseudo-tag calculation'. It technically is our responsibility to extract the relevant information out of the osm database.

[quaelnix]

What do you think about replacing:

The percentage is converted to a factor and the factor is assigned to a class. For traffic, calculations are on another level of complexity. A way can be long and go through different environments, so a class is average for the whole way length. To improve calculations one can divide such ways at junctions by editing in OSM.

with:

The percentage is converted to a factor and the factor is assigned to a class. Long ways that pass through different environments can be problematic because the class is based on the average environment along the entire way. For traffic, calculations are on another level of complexity.

[Stapawe]

I don't see negative consequences of splitting ways, and there are good chances that a person splitting ways will make other changes, but if there is no majority, I think it should be written what we can agree on, and editorially your proposal is better.

[quaelnix]

Feel free to change the phrase some more in case you still dislike it. I am fine with any wording as long as it does not actively encourage people to split OSM-ways because it improves pseudo-tag generation.

I also think that we should squash all the minor commits into the first one before we merge this pull request.

[quaelnix]

@Stapawe, what do we do about the problem that currently all the distance data is wrong? It would probably be quite an effort to keep this data constantly updated, since it will probably change some more until at some point we hopefully find an optimum.

[Stapawe]

Do you mean buffer distance are wrong because of this: https://github.com/abrensch/brouter/blob/76265e7713ad203ee6679a810121d2bd22f78074/misc/scripts/mapcreation/brouter.sql#L47 I can't verify it. Does ratio of length transformations in two coordinate system is constant for different latitudes? How much? Updates of values in documentation is easier than in code, there could be a request in the comment.

[quaelnix]

Do you mean buffer distance are wrong because of this:

Yes:

• osm_line_buf_50 is currently 32.15 m wide.
• osm_poly_buf_120 is currently 45 m + 32.15 m = 77.15 m wide.

Does ratio of length transformations in two coordinate system is constant for different latitudes?

As far as I can tell, the code works as expected:	Latitude 0	Latitude 55
https://www.openstreetmap.org/way/591384096	https://www.openstreetmap.org/way/354647739
https://brouter.de/brouter-web/#map=18/0.09112/-51.10462/standard,route-quality&lonlats=-51.104835,0.091816;-51.104358,0.091622	https://brouter.de/brouter-web/#map=17/-54.82980/-68.34195/standard,route-quality&lonlats=-68.342605,-54.82975;-68.341323,-54.829872

[Stapawe]

Good examples. So buffers are no bigger than ~60 m wide, adding 2 sides of a way. If it is 32.15 then st_length (ST_Transform (way, 3857)) / st_length (ST_Transform (way, 4326)::geography) have to be 1, making it redundant. Do you want to open an issue about this? GitHub is bad for multithread discussions and phrase "st_length (ST_Transform (way, 4326)::geography)" is not known by Google.

[quaelnix]

@Stapawe, this article explains the underlying issue pretty well: https://blog.rustprooflabs.com/2023/04/postgis-geometry-accuracy

[Stapawe]

I hope I've got it: In Web Mercator (3857) number of meters increase with latitude for the same real distance. So this transformation is to increase Web Mercator meters for processed ways to keep real distances the same. Smart.

[Stapawe]

Thanks, I forget to check all examples

[quaelnix]

@EssBee59, did you have time to take a look at it yet?

[quaelnix]

@Stapawe, thanks again for the work you put into this documentation!

[Stapawe]

@quaelnix, once again :) thanks for your scrutiny and your whole work put in Brouter