Overleg:Non-drivable roads lock level Geschiedenis weergeven

(Added list of arguments)
Geen bewerkingssamenvatting
 
(Een tussenliggende versie door een andere gebruiker niet weergegeven)
Regel 1: Regel 1:
===Arguments '''for''' locking at '''L3'''===
===Arguments '''for''' locking at '''L3'''===


* A segment locked at '''L3''' is seen as confirmed, as non-drivable segments are removed if they do not contribute to routing
The idea behind the locking was to limit the number of PB's and WT's as much as possible. So an Area Manager could check the non-drivable segments. If the AM thought they should stay, the AM would lock on L3 or otherwise delete the segment. If the segment was recently added the editor who added it should be contacted to explain why the segment is deleted.
** In practice this only applies to the Netherlands, Belgium does not do this
 
* Walking Trails have an effect on routing, so they should be locked
The locking standard makes sense because of the routing consequences of improper mapped non-drivable roads with possible destinations. Disconnecting of a WT can have a great impact on the routing. Since the introduction of parking place suggestions based on walking time, connecting PB's is also of the utmost importance. Locking is important because the role of the non-drivable roads is not for every (starting) editor clear.<br />
** The same logic would require all regular streets to be locked at the same level, but obviously exceptions can be made
* In practice this only applies to the Netherlands, Belgium does not do this.
* The logic between the categories of non-drivable segments is a bit more complicated for new editors
<br />


===Arguments '''against''' locking at '''L3'''===
===Arguments '''against''' locking at '''L3'''===
Regel 12: Regel 12:
* Since the introduction of phantom nodes, connecting non-drivable segments no longer creates unwanted nodes on the drivable segments
* Since the introduction of phantom nodes, connecting non-drivable segments no longer creates unwanted nodes on the drivable segments
* There are hardly any reports of errors based on this sort of routing, making a high level lock feel like overkill
* There are hardly any reports of errors based on this sort of routing, making a high level lock feel like overkill
* House numbers are a lot of work, so the more editors can do this, the better it will be
* What the best place to park/stop with a car is, requires local knowledge, of course combined with editor knowledge. But again to more editors can edit these segments, the more local knowledge is used
<br />


===Things everybody seems to agree on===
===Things everybody seems to agree on===
Complex situations should always be locked appropriately. If a segment is important for proper routing, it should be protected against mistakes of starting editors.
Complex situations should always be locked appropriately. If a segment is important for proper routing, it should be protected against mistakes of starting editors.

Huidige versie van 14 jun 2018 om 22:33

Arguments for locking at L3

The idea behind the locking was to limit the number of PB's and WT's as much as possible. So an Area Manager could check the non-drivable segments. If the AM thought they should stay, the AM would lock on L3 or otherwise delete the segment. If the segment was recently added the editor who added it should be contacted to explain why the segment is deleted.

The locking standard makes sense because of the routing consequences of improper mapped non-drivable roads with possible destinations. Disconnecting of a WT can have a great impact on the routing. Since the introduction of parking place suggestions based on walking time, connecting PB's is also of the utmost importance. Locking is important because the role of the non-drivable roads is not for every (starting) editor clear.

  • In practice this only applies to the Netherlands, Belgium does not do this.


Arguments against locking at L3

  • Locking at level 3 will block new editors from adding missing non-drivable segments or adjusting connected local roads, causing frustrations
  • Since the introduction of phantom nodes, connecting non-drivable segments no longer creates unwanted nodes on the drivable segments
  • There are hardly any reports of errors based on this sort of routing, making a high level lock feel like overkill
  • House numbers are a lot of work, so the more editors can do this, the better it will be
  • What the best place to park/stop with a car is, requires local knowledge, of course combined with editor knowledge. But again to more editors can edit these segments, the more local knowledge is used


Things everybody seems to agree on

Complex situations should always be locked appropriately. If a segment is important for proper routing, it should be protected against mistakes of starting editors.