[Talk-lt] secondary/tertiary in proposed definitions at WikiProject Lithuania

Mateusz Konieczny matkoniecz at tutanota.com
Tue Jun 7 13:58:12 UTC 2022




7 cze 2022, 15:36 od a.kasparas at gmc.lt:

> First, the official classification outside cities in Lithuania is quite good. I know just one road which do not have road number when it probably should have. I don't know location where change of classification would be appropriate. We would be glad to make an exception for road or two which would produce illogical result.
>
glad to hear this!

> Second, every year some country roads are paved. This is done taking into account importance of the stretch of the road (plus, if it goes over some village). So, important stretches gets paved and upgraded in the OSM database. If more gaps are left, then the whole road is less important in country's or wider context. So state of map reflects state on the ground. In our book this is how things should be.
>
Also when it results in a short strips of higway=tertiary upgraded to highway=secondary
because section of say 30m or 100m or 300m was paved?
As far as I know, this is really unusual and goes against how highway=.../primary/secondary/
teriary/... is in general mapped or should be mapped.

> Third, there are different legal requirements while driving on paved roads and on unpaved roads -- 90 vs 70 km/h max speed, right of the way for driving on first vs second.
>
this, as far as I know, can be easily achieved by tagging and using surface=* tags
(some places have different legal rules on lit/unlit single/double carriageways,
inside/outside settled areas and so on and trying to fit it into highway=* classes is rarely
the best idea)

> Forth, in all practical applications we could come up at the time of the decision we expected that one will work with set where all or none of secondary and tertiary will be included. So, we considered this to be safe.
>
sorry, I do not really understand this part

> Fifth, number of map errors in LT is way lower than in neighboring countries.
>
I am a bit skeptical about count of QA errors as map quality metric, but it is
probably better to leave it for another discussion (though I am also a validator
enthusiast)

> But this does not mean that he could do whatever he wants. I do remember when mine and his opinions were different. But technical arguments always prevailed. On some occasions mine were accepted, on others -- Tomas'. So, he is not a dictator here.
>
Even more glad to hear this!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-lt/attachments/20220607/85675e81/attachment.htm>


More information about the Talk-lt mailing list