Informações úteis direto dos devs

[antigerme]

[b]Pessoal,

vou criar este tópico para “colar” informações uteis que os devs nos passam, normalmente dúvidas frequentes.

Juro que vou tentar manter isso sempre atualizado. ;)[/b]

Quem quiser acompanhar, não esqueça de se inscrever no tópico.

[antigerme]

http://world.waze.com/forum/viewtopic.php?f=557&t=42906&p=415325#p415325

@shirlig

Explanation about traffic jams:
Some clarifications:

1. You should distinguish between two things:
   The first is what we call “measurements”, which is the speed on a certain segment. This is calculated from users driving, and is pretty much immediate (a couple of seconds). So, if users drive slow on a certain road, the system will know it immediately, and base its ETA calc and routing on this immediately.
   The second is what we call “jams”, which is the coloring of streets to visualize irregularly slow traffic. There is an algorithm which tries to determine jams based on measurements, the road type, and other factors. This process runs normally every minute, but when the system is loaded can take several minutes.

2. When a user reports traffic as an alert, it has two effects:

• it creates an “alert” on the map (like any other alert: accident, police, etc)
• it gives a higher weight to the speed the user is actually driving in.

Our reference speed to calculate traffic jams is different in the NA and in the INTL servers and none of them works as they ideally should.
in the NA sever: the reference is the speed of road type
in the INTL server: the reference is the maximum between the speed of road type and the historic data.

As I said, we are not fully satisfied with none of the two behaviors above.
We are working on improving it so that it so that the reference speed to calculate a traffic jam will be the real driving speed on the segment when the road is completely free.

We will keep you posted about this issue soon.

Thanks,

Shirli

http://world.waze.com/forum/viewtopic.php?f=557&t=42906&p=416352#p416352

@eshabtai

@CBenson

However, if the severity of the jam is not based on data for the specific time of day, then it seems to me 1) we are misleading people and 2) the jam highlights are not working as designed. I say 2 because there are plenty of times where there are many wazers on a slow freeway or major highway where there is no jam indicated.

Regarding #2, there is a known issue that it may take several minutes for the jam highlights to actually show especially on rush hour so that may explain why you’re seeing many wazers stuck on a jam and no highlight.

And just to be clear, the fact that you do not see the highlight does NOT mean that the routing system is not aware of the jam. I think that’s the real confusing part. The routing real time data and jam highlights are two separate systems.

Ehud

[antigerme]

http://world.waze.com/forum/viewtopic.php?f=18&p=446480#p446480

@shirapashu

Hi All,

For your information, area managers are now automatically removed after 90 days of inactivity.

They can ask again for permission by filling this form.

Thanks,

Shira

[antigerme]

http://world.waze.com/forum/viewtopic.php?f=294&t=55464&p=519436#p519436

@amitbena

Hi Guys,

Thanks for your patience.

As promised, a bit more information about the “detour detection mechanism”:

The “detour detection mechanism” tries to prevent routs alternatives that exit major roads into minor roads (ramps, streets etc.), in order to save negligible driving time.
The idea is that drivers will prefer to remain on the major road, even if it is just a bit longer or slower.

The following scenarios are considered as a detour, and will not be shown as a possible route alternative:

• If the start point of the detour and end point of the detour have the same street name (only main street name - not alternative name)
• Detour must be more than 1 segment long (between 2 segments with the same name).

The mechanism handles 2 types of detours with slightly different properties:

• Highways:
• Road types: Freeway, Major Highway - it’s a detour only if the detour started out of these types, got back to these types, and in the middle the types are different.
• Bypass length is 5km - under this threshold, the route is considered to be a detour and will not be shown as a possible route. If it is longer then 5km, it will be considered as a valid new route - and there for will be shown as a possible route.
• Minor Highway:
• Road types: Minor Highway - same role here, it’s a detour only if the detour started out of these types, got back to these types, and in the middle the types are different.
• Bypass length is 500m - again, same role here as well, under this threshold, the route is considered to be a detour and will not be shown as a possible route. If it is longer then 500m, it will be considered as a valid new route - and there for will be shown as a possible route.

Thanks,

Amit

[antigerme]

http://world.waze.com/forum/viewtopic.php?f=211&t=52336&p=478100#p478100

@ohad-ron

Some answers -

The road ranks are calculated based on two things - how old the segment is, and how busy it is.

vincio60 - the roads you have given as example were only created four months ago. It makes some sense to let more people to edit it, and if not - you can always manually lock it.

peter - this road is actually quite busy and quite old in our system (since 2010). There’s theoretically a small chance it will need modifications. Are you sure it’s that insiginificant?

We have a known problem with tunnels - the road rank algorithm does not understand (yet) that people have been driving through that segment but without any gps points because it is a tunnel. We will need to set the locks manually there as well.

http://world.waze.com/forum/viewtopic.php?f=211&t=52336&p=478100#p478106

@ohad-ron

@petervdveen

Is the amounth of editors in the area a factor?

No, just in the country / state.

@petervdveen

If there is an area with no editors all roads are very old, but probably not correct

Well, it is a very unique case - having a place with old roads, which are not driven on, with no editors. Let me know if you see a case like this so we can fine-tune.

@petervdveen

Btw, is it possible a segment has a road-rank of rank 6?

Only if there are enough rank 6 editors in the country

http://world.waze.com/forum/viewtopic.php?f=211&t=63257&p=568748l#p568748

@ohad-ron

…

• Road Ranks - To answer your questions: Road ranks are calculated independently per country. It relies on the count of how many people have ever driven the affected segment. For each country there are different values for what count should lock a segment on a certain lock rank. If you create a new segment, depends on the country and location, it can take a while until it will be locked automatically. Road ranks are already effective in production in some countries. If I remember correctly, Italy and Romania. In beta: Brazil, Hungary, Netherlands, UK.

http://world.waze.com/forum/viewtopic.php?f=211&t=63257&p=568759#p568759

@ohad-ron

Are these country-specific values dynamic - do they change when, after some months, the wazing population has doubled? If one country’s local champs think the ranking is too loose or too thight, can it then be adjusted by some factor?

Currently the update is done manually but we are working on a process that will do it automatically monthly, to adjust for waze-population increase.
It can be adjusted by some factor if the local champs think there are unique circumstances.

[antigerme]

Essa foi por email e há muito tempo já deveria ter divulgado.

BRAZIL
Street type affixes:
Alameda=Al. (boulevard)
Avenida=Av. (avenue)
Estrada=Est. (dirty highway)
Rodovia=Rod. (highway)
Rua=R. (street)
Travessa= Tv. (bystreet)
Beco=B. (alley)
Direction affixes:
Norte=N (north)
Sul=S (south)
Leste=L (east)
Oeste=O (west)
Noroeste=NO (northwest)
Nordeste=NE (northeast)
Sudoeste=SO (southwest)
Sudeste=SE (southeast)
Common abbreviations:
Balneário=Bal.
Beco=B.
Bloco=Bl.
Chácara=Ch.
Conjunto=Cj.
Fazenda=Faz.
Galeria=Gal.
Granja=Gja.
Jardim=Jd.
Largo=Lg.
Loteamento=Lot.
Parque=Prq.
General=Gen.
Praça=Pç.
Praia=Pr.
Quadra=Q.
Setor=St.
Via=V.
Viaduto=Vd.
Vila=Vl.
Agrícola=Agr.
Coronel=Cel.
Deputado=Dep.
Desembargador=Des.
Direita=Dir.
Divisão=Div.
Dona=Da.
Governador=Gov.
Júnior=Jr.
Marechal=Mal.
Marginal=Marg.
Ministro=Min.
Padre=Pe.
Presidente=Pres.
Professor=Prof.
Vereador=Ver.
Doutor=Dr.
Engenheiro=Eng.
Esquerda=Esq.
Prepositions
a, de, em, para, com, por

General query pattern
Location of house numbers in the search:
After street name. <streetname>, <housenumber>
Location of the zipcode:
After city name. <streetname>, <housenumber>, <cityname>, <zipcode>
Zipcode format:
5 digits “-” 3 digits. <XXXXX>-<XXX>

Examples:
Searches with house number:
Rua Miguel Santos Silva, 48
Avenida Luiz Tarquinio, 19, Lauro de Freitas
Searches with zipcode:
Rua Miguel Santos Silva, 42700-234
Avenida Luiz Tarquinio, 19, 42700-230
Full searches:
Rua Miguel Santos Silva, 48, Lauro de Freitas, 42700-230
Avenida Luiz Tarquinio, 19, Lauro de Freitas, 42700-234
Partial searches:
Rua Miguel Santos Silva, 48
Avenida Luiz Tarquinio, Lauro de Freitas
42700-234
Lauro de Freitas, 42700-230
Searches for streets that contain numbers in their name:
Avenida 1 do CAB, 13, Salvador, 41730-010
2 Travessa de São Jorge, Lauro de Freitas

House numbers
House numbering system:
Same system.
Some very small towns that do not follow the numbering pattern.
Mandatory alphanumeric characters:
No mandatory

CEP não é suportado na pesquisa na base do Waze, só Google.

[antigerme]

Este foi por email

@/me

Guys,

Can you help me with this mystery? Some users are complaining of longer routes. See this example below.

Why Waze did not provide me the best route (default route/first option)?
[hide][/hide]

Livemap
https://www.waze.com/pt-BR/livemap?lon=-40.34857&lat=-3.68951&zoom=17&from_lat=-3.73186&from_lon=-38.52667&to_lat=-3.68951&to_lon=-40.34857
[hide][/hide]

May the Force be with you!

@resposta do Ori

Hi,

I will investigate it with the team first thing tomorrow.

Thanks!

Join the dark side…

@resposta definitiva do Ori

Hi,

We did some research, and by we I mean of geo team and Ron.
This is their finding:

There is no problem with the route, the second route goes through 6 cities which means many street (minor / major) road type, while the first route (suggested one) has only 2-3 cities so waze will prefer to use this route (with more highways, less cities with low road type - street), it’s all about penalty.

Having said that, our algorithm guys are interested in this example and reviewing it so they can conclude more about Waze’s route predictions.
If you have more examples like this one, I would appreciate if you could share it, so the ultra-brains can study them.

So…who’ll take the cup?

Agora posso continuar minha “briga” para não descaracterizarem as rodovias em áreas urbanas? estou encontrando gente rebaixando rodovias para Primary/Street. :shock:

[antigerme]

Uma pequena atualização sobre o mecanismo. Teremos o mecanismo funcionando para as pequenas escapadinhas.

https://www.waze.com/forum/viewtopic.php?f=1087&t=76481

@amitbena

A bit about detours…

We need to differentiate between “big” and “small” detours.

Big Detours
Freeways / Major & Minor Highways detours - aka “Detour Detection Mechanism”

Refers to the use-case of exiting a highway/freeway and returning to the same highway/freeway. The “detour detection mechanism” tries to prevent route options that exit major roads into minor roads (ramps, streets etc.), in order to save negligible driving time.
The idea is that drivers will prefer to remain on the major road, even if it is just a bit longer or slower.

Detection of detours is mostly based on the street names - (If I drive on a segment named x, move to a segment named y and go back to segment x - the server will recognize it’s a detour and will avoid this kind of route).

As published before, the following scenarios are considered as a detour, and will not be shown as a possible route alternative:

• If the start point of the detour and end point of the detour have the same street name (only main street name - not alternative name)
• Detour must be more than 1 segment long (between 2 segments with the same name).

The mechanism handles 2 types of detours with slightly different properties:

• Highways:
• Road types: Freeway, Major Highway - it’s a detour only if the detour started out of these types, got back to these types, and in the middle the types are different.
• Bypass length is 5km - under this threshold, the route is considered to be a detour and will not be shown as a possible route. If it is longer then 5km, it will be considered as a valid new route - and there for will be shown as a possible route.
• Minor Highway:
• Road types: Minor Highway - same rule here, it’s a detour only if the detour started out of these types, got back to these types, and in the middle the types are different.
• Bypass length is 500m - again, same rule here as well, under this threshold, the route is considered to be a detour and will not be shown as a possible route. If it is longer then 500m, it will be considered as a valid new route - and there for will be shown as a possible route.

What’s new?:
1- Alternate street names: take into account alternate names, too. So, if one of the alternate names match the given name, we’ll consider it the same name.
2- Unnamed streets: if 2 segments are unnamed, they are not considered to have the same name anymore.
3- ‘in the middle the types are different’ - we removed this ‘limitation’, so now we can detect highway detours that do have one or more segments of type highway (but do not belong to the highway the detour started from and ended in).

These changes are deployed as we speak and awaiting the new builder from IFS as well.
We’ll update you when they will all be deploy.

Small Detours
When historic data creates unreasonable routes to cut time - Refers to “weird” routes within the city and in neighborhoods.

Use-case: Many times, Waze prefers to continue straight, make a u-turn and turn right instead of just turning left in the junction just to save a few seconds. Very often this is perceived as a mistake and not as a time saving.

What’s new? (enabled and tested in the staff server at the moment)
1- Under 30 sec difference - the routing will not take the detour
2- Over than 30 sec difference - the routing will take the detour while providing an explanation (the explanation part is still not supported in the client, will be implemented in future versions).

[antigerme]

Nada de copiar mapas de outros locais.

https://www.waze.com/forum/viewtopic.php?f=212&t=105733#p872084

@adriansinger

Hi Dear Champs,

We really appreciate the time and effort you put into creating tools that help the community. However, for legal reasons those tools need to follow some guidelines.

We wanted to kindly remind you all that it is strictly prohibited to use external data unless specifically verified and approved by our legal team. Please keep in mind that this is also relevant for editing tools developed by the community, and these tools should be free of any reference to external data.

Thank you,
Adrian

https://www.waze.com/forum/viewtopic.php?f=212&t=105733&start=20#p872414

@adriansinger

Hi all,

I understand that perhaps the message was not clear and so I would like to clarify.

As a starting point, this was never intended or done as an accusation rather as more of a reminder which we do from time to time.

Overall it is clear some sources are valid and OK, specifically all public sources, such as road signs, information publicized as open free data (information from news paper as an example, on major events, roads closures, etc.), Waze related resources (such as Google street view or Bing aerial info we had before) and other local sources which constitute open public information.

What should not be used is information from commercial 3rd parties (HERE as an example) or information with conflicting licensing issues (OSM as an example). The Navis example is exactly what we want to prevent in our maps, as certain parties do protect their data with “Easter eggs” (which could be imaginary roads or wrong road names as well).

Please note that even Google map data, in some countries, is not authorized for use in Waze as the licensing of the map data prohibit such usage. This is why we ask, in case of uncertainties, to consult with us on these matters, so that we do keep the map as “clean” as possible.

We have always trusted the community in their work and specifically trusted their knowledge and experience to follow these guidelines (which we also mentioned several times in the past). As I indicated, this message was intended to be similar to those previous reminders and we did not expect it to be seen as different in that respect, but I understand that it was not clear and apologize for that.

Adrian

https://www.waze.com/forum/viewtopic.php?f=212&t=105733&start=60#p874261

@shirlig

Hi guys,

The rules regarding the use of third party data are not new. We have always been very clear and consistent about it in multiple discussions we’ve had in the past, in our terms of use and in the wiki.
Those of you who are here for a long while already, might remember that a few years ago, with a heavy heart, we even had to delete the entire map of Argentina for licensing reasons.

The fact that it comes as a surprise makes us realize that this reminder was needed and we’re happy it came up so we can clear things out.
Third party content such as Bing maps, HERE, OpenStreetMap, etc. cannot be used to map Waze.

External data that can be used:

• Public sources i.e news paper publication, government bulletins, TV news reports, municipalities open data listing, etc.
• Specific sources that have been verified and approved by Waze staff.
  We will work on providing a list of sources that have been already approved and will make sure to keep it updated.
  To map Waze you can use any information available in the editor including GPS points, update requests, aerials, Google street view and your knowledge of course.
  In addition, we will work to provide you with a list of Google Maps countries that can be used by Waze.

As many champs often do, if you have any doubt regarding a source, please send it to us and we’ll be happy to check them for you.

We hope that makes everything clearer and trust our Global Champs to follow our terms of use and set an examples to new editors in your local communities.

Thanks,
Shirli

[antigerme]

https://www.waze.com/forum/viewtopic.php?f=212&t=105563#p870712

@redviper26

Hey guys,

We started a process that identifies users who cheat on reports or drives. In both cases we identify users who crossed a threshold (a very high one) of reports or of daily driven KM more then once. These users are blocked from reporting or editing, respectively, and the points gained through these actions are deduced. In both cases those users are removed from the scoreboard.

We’ll monitor the process and adjust as necessary

Noam

https://www.waze.com/forum/viewtopic.php?f=212&t=105563&start=10#p871880

@redviper26

Hey guys,

Thanks for your feedback - we always appreciate helpful and constructive suggestions.

We posted here to let you guys know, and so that you can provide answers to the community.

Regarding thresholds - these were set extremely high. A user has to pass a very high threshold several times before he is blocked. If you believe there is a bug in the system we will check. But it is possible some good editors fake drives and don’t think it’s an issue. It’s important to let them know it is an issue that we are serious about, as it disrupts the scoreboard and affects other users.

We will also look into the mail’s phrasing - this is the email sent to all blocked users, it’s not a new one.

Thanks,

Noam

https://www.waze.com/forum/viewtopic.php?f=212&t=105563&start=20#p872219

@redviper26

Guys,

If a user is blocked he can reach out for support and ask us to unblock him. We’re examining the emails sent to clarify this.

You come into play if this is an editor/user you know and vouch for. Since we trust you, if you ask us to unblock a specific user, we will. It’s not a function you need to perform.

Noam

[antigerme]

Por favor, nada de ficar armengando no editor criando junções artificiais com o objetivo de fazer uma representação fiel ao tamanho da ponte/viaduto, ou preguiça de fazer cruzamento sem junção usando elevações.

Volta para o mar armengue… :mrgreen:

https://www.waze.com/forum/viewtopic.php?f=212&t=72276&start=50#p799633

@mushonz

Hi guys,
We are preparing some more specific guidelines regarding tunnels and bridges but in the meanwhile here are some quick responses:

Yes, much of what you’re writing here is echoing the questions we’ve been bouncing around here, and yes, marking tunnels ground levels and bridges can be tricky as road interchanges become more complex. I want to emphasize though that this is not only about marking the z-axis order of roads or the exact locations of tunnels, we are actually trying to make sure we differentiate tunnels, bridges and ground levels as these also serve as visual cues for drivers. So we need a single unique level for ground and multiple levels for tunnels and bridges.

The seagull rule

The rule we suggest involves a bird. Let’s say a seagull:

• If the seagull can fly right under it, it’s a bridge (level > 0).
• Unless our seagull is flying underground (why would it?), in which case it’s going in a tunnel (level < 0)
• For every other case the road is ground level (level = 0), even if it’s artificially elevated or dug under street level.

More best practices:

• We mark bridges with level = +1.
• We only mark a road as level +2 if there’s another bridge (+1) running underneath it.
• Same logic goes for +3 +4 …
• Same logic goes for -2 -3 tunnels…

We are currently working on similar features to distinguish elevation levels in the editor map as well, we will tell you more about it when we have more information. But for now we can say that this is one of the features that would go into the new editor map and we promise it will launch before tunnels and bridges are emphasized in the client map.

In the meanwhile this feedback is helpful. Keep it coming. For example:

@AlanOfTheBerg

There are also complex freeway interchanges which require more than 10 different levels if one wants to ensure than no two crossing segments show as intersecting.

Can you post a link to such an intersection that requires the use of so many level hierarchies?

Thanks!

https://www.waze.com/forum/viewtopic.php?f=212&t=72276&start=80#p807697

@mushonz

Ok, after running this issue through a few people in a couple of different departments here the verdict is out. If I may quote myself:

@mushonz

1. How should we address same level crossing roads that do not allow turning from one segment to the other? Should they ignore the overlap (basically act like a road and a bridge crossing above it) or should they always create a node and simply prohibit the turns from one road to the other?

Answer:
A junction should always be a node and the routing options on that node should be edited accordingly. Even in cases where the junction does not introduce additional turns (essentially both roads only allow continuing straight) there should be a node connecting them and echoing the physical interconnection. There are many other reasons, including making sure the experience of the driver is echoed by the data on the server, and to process the penalty that this crossing should entail. But more generally, we should always strive to stick to an accurate representation of the map and to keep the routing interpretation to the algorithms. Every rule has exceptions, but we agreed that this specific issue should not be one.

@mushonz

2. Would splicing segments to smaller chunks for metadata (elevation) accuracy purposes affect time on segment and jam detection? And if so should that prohibit us from adding the accurate elevation data into the map?

Answer:
We have looked into this one as well and it seems that such an effect will be negligible and we will work to minimize or completely eliminate any unnecessary penalty. In this case too, we choose tp stick to an accurate representation of the map with tight marking of bridges (level > 0) and tunnels (level < 0).

Finally,
we’re working on a more detailed set of guidelines so stay tuned for more updates both about the live map and about the editor map. But for now I am happy that the answers we got do not require ugly hacks, separate routing logic from the map’s representation of ‘facts on the ground’, and in that way are elegant and forward looking.

Thanks!

https://www.waze.com/forum/viewtopic.php?f=212&t=72276&start=100#p818736

@mushonz

Hi guys,
This might be a bit abstract so bare with me and I hope this would help to explain why we actually need to stick to the more conservative use of elevation levels.
I’m afraid your suggestion of a separate parameter for tunnels and a relative-only use of the elevation level would only get us so far. It would only let us know what is a tunnel and what order to layer the segments by, but It would not allow us to know if it’s a bridge or a ground level segment. It would not allow us to know if a road is going on a bridge or off a bridge as the editor simply marked the road under it with a lower elevation level. Moreover, it would not allow us to group elevation levels together as one road could have multiple elevation levels on segments (-1, -4, -9) even if they’re trying to say the same thing (as in: “this road is lower than the 0 level”). You have to understand that the map engines (both client, livemap and editor) do not “know” the relationship between segments, they only know in what order to draw them. In order for us to express this relationship we need to add metadata that groups segments together not only orders them. Otherwise, our ability to deliver the best and most accurate maps is dramatically limited.
I realize a simple checkbox would’ve been easier to work with and that was actually my initial plan, but it does not deliver the desired result.
I hope this doesn’t frustrate you too much, but at least the way I see it, there is no way around sticking to a more conservative use of the elevation levels as in:

+3 = (bridge that is higher than the 2 bridges that goes under it)
+2 = bridge (that is higher than the bridge that goes under it)
+1 = bridge (elevated from ground level)
0 = ground (only dirt, worms and prehistoric remains under the pavement)
-1 = tunnel (dug in the ground, reduced sunlight or electronic signal in sight)
-2 = tunnel (going even deeper than -1 and passes under it)
-3 = tunnel (deep deep in the ground with two other dug tunnels above it) a bit like “London Below”:
[youtube]https://www.youtube.com/watch?v=IfBaC-O0amY[/youtube]

I hope this makes more sense and helps explain the guidelines I introduced earlier.
Thanks,
Mushon

https://www.waze.com/forum/viewtopic.php?f=212&t=72276&start=110#p818826

@mushonz

@Timbones

(unavailable attachment: elevation2.png)

a. This is a beautiful diagram.
b. This cannot be done unless the segment “knows” of the segment above it. This is unfortunately not how the map engines work, to do that the engines would’ve needed to run much more real time calculations which would not really work.
c. We’re trying to shoot for higher standards here. And there’s no doubt that currently the map is lacking in accurate elevation data. Yes the current state is usable, but only as much as rice cakes are edible. We want the map to be delicious.
d. None of the above means we’re planning to sacrifice performance for aesthetics or even for map accuracy. There are ways for the algorithm to decide when to add a node, how to treat it and so on… Getting too technical with explaining it would be hard and very boring, but trust us, we do not intend to allow this to affect routing and performance in any way negative. Quite the opposite.

I will discuss your feedback with the community team and let them continue from here, and follow up with more official guidelines.

Thanks for your thoughtful and committed feedback,
Mushon

Muita discussão, GC de todos os países se digladiando, sangue jorrando, a Shirli bate o martelo (fatality), acaba a discussão do pessoal querer armengar e tranca o tópico.

https://www.waze.com/forum/viewtopic.php?f=212&t=72276&start=120#p823801

@shirlig

Hi guys,

Thanks for all the feedback regarding this important issue.

As I wrote in this post, there is currently NO NEED TO CHANGE ANYTHING in your editing practices. In other words, do not split roads or anything else to adjust to the new livemap design.

We will verify extensively of all aspects related to this matter, and make sure to provide you with clear guidelines for elevations mapping. Until then, I’d like to wrap thing up. I’m closing this thread to avoid any further confusion.

If you feel that other mapping questions need to be addressed (not related to the new livemap) please open a new thread in the direct access forum and we will do our best to help.

Thanks!
Shilri

[antigerme]

Mais um que é antigo e que só lembrei de postar agora por causa de um editor, ele disse que isso de “5m” é balela . :evil:

Resumindo, nada de segmentos menores que 5m, cruzamento é cruzamento e tem que ser da forma correta - nada de esquecer a junção ou usar elevações diferentes - e americano gosta de inventar.

Na parte do “americano criativo” soon teremos uma nova Wiki completamente descontaminada da invenções americanas, o Waze deu um bom chega para lá neles, não é por a Wiki INT ser em inglês que é a página americana. :lol: :lol:

https://www.waze.com/forum/viewtopic.php?f=212&t=77601#p667592

@redviper26

Hey guys,

Following our map quality team’s work, and feedback and suggestions from several champs, we are about to add new types of problems to the WME.

The new map problems will be issues identified automatically according to the parameters listed in the table below. They’ll be added to the editor with suggested solutions, based on the the combined suggestions of the map quality team and the community.

Our goal is to make sure we’re all aligned on best practices and the best solutions for problems, guaranteeing a useful, accurate and good looking map.

The first 6 map problems will be the following:
[table][td]#[/td][td]Name[/td][td]Problem Description[/td][td]Solution[/td][td]Link[/td][tr][/tr]
[td]1[/td][td]Disconnection[/td][td]The highlighted segment is disconnected.[/td][td]1. Connect the highlighted segment and remember to open the relevant turns.
2. Adjust the direction of the segment.[/td][td]Editor link[/td][tr][/tr]
[td]2[/td][td]Crooked Segments[/td][td]The highlighted segment has an acute angle between the geo-nodes[/td][td]Try to match the segment’s geometry to the real life road geometry (by deleting the unnecessary geo-nodes or smoothing the angles).[/td][td]Editor link[/td][tr][/tr]

[td]3[/td][td]Routing Problem[/td][td]The highlighted segment doesn’t match its connected segments directions.[/td][td]Open the turns from the segment to allow routing, or adjust its or the surrounding segments directions.[/td][td]Editor link[/td][tr][/tr]
[td]4[/td][td]Overlapping Segments[/td][td]The highlighted segment geometry overlaps another segment’s geometry.[/td][td]Move or delete one of the overlapping segments.[/td][td]Editor link[/td][tr][/tr]
[td]5[/td][td]Intersecting Segments[/td][td]The highlighted segment crosses another segment with the same elevation without a junction point.[/td][td]Create a junction between the highlighted segments, or adjust the elevation of the segments.[/td][td]Editor link[/td][tr][/tr]
[td]6[/td][td]Short Segment[/td][td]The highlighted segment is shorter than 5m.[/td][td]Delete the highlighted segment and connect the segments/junction, or make the highlighted segment longer than 5m.[/td][td]Editor link[/td][tr][/tr][/table]

This is the first batch. We intend to add more issues gradually, in collaboration with you guys.

Let us know what you think,

Noam and Amit

https://www.waze.com/forum/viewtopic.php?f=212&t=77601#p667610

@redviper26

Hi Sketch,

Thanks for the positive feedback, it’s very important to us

Regarding short segments - when a segment is shorter then 5M the system can’t get the required info about drives through it, making it hard to calculate cross-time properly, Which impacts ETA calculations.

Thanks again,

Noam

https://www.waze.com/forum/viewtopic.php?f=212&t=77601#p667622

@redviper26

The main issue with elevation levels is when two segments in the same elevation cross each other with no junction. It also affects the map’s presentation in the client, and may affect other issues in the future.

Thanks,

Noam

https://www.waze.com/forum/viewtopic.php?f=212&t=77601&start=10#p667641

@redviper26

@doctorkb

@redviper26

Regarding short segments - when a segment is shorter then 5M the system can’t get the required info about drives through it, making it hard to calculate cross-time properly, Which impacts ETA calculations.

So… does it just ignore it, or does it really mess things up?

I have a couple of these: https://www.waze.com/wiki/Junction_Style_Guide#Wayfinder_Segments that for visual purposes are very short (~2m). The recommended 15-20m was too long, visually.

I’m afraid it messes things up… we need them to be longer then 5M.

[antigerme]

Sério, o povo adora inventar moda e depois se ferra. Pensam que criatividade é coisa exclusivamente brasileira? que nada, acho que é geral da comunidade latina.

Só me vem a cabeça a seguinte frase:
Chupaaaaa! Eu te disse!!!

Olhem só o “profissionalismo e capacidade criativa” dos nossos hermanos…

https://www.waze.com/forum/viewtopic.php?f=635&p=1102153#p1102153

@deblaks

Estimados champs,

Conocemos la necesidad que tienen las comunidades de América Latina de poder reportar “Obstáculos Permanentes” (Permanent Hazards) y que el TTS los reconozca como tal.

Sus sugerencias son muy importantes para nosotros y ya estamos trabajando para poder incluir esto como una opción en las próximas versiones de la aplicación. El proyecto consiste en incluir de forma manual en el WME cómo el editor quiere que el TTS pronuncie la instrucción.

Otro proyecto en el que estamos trabajando es en incluir una función llamada “Obstáculos Permanentes”, la cual permitirá añadir al mapa esos obstáculos que hoy ustedes sienten la necesidad de añadir de forma irregular (lomos de burro/policías acostados, peajes peligrosos, etc.).

Durante los últimos Meetups Locales nos enteramos que varias comunidades están creando “work-arounds” o soluciones alternativas para poder dar esta solución a los usuarios. Estos son algunos ejemplo de lo que están haciendo algunas las comunidades:

(unavailable attachment: Screen Shot 2015-05-05 at 11.26.19.png)
(unavailable attachment: Screen Shot 2015-05-05 at 11.26.28.png)
(unavailable attachment: Screen Shot 2015-05-05 at 11.26.40.png)
(unavailable attachment: Screen Shot 2015-05-05 at 11.26.50.png)
(unavailable attachment: Screen Shot 2015-05-05 at 11.27.02.png)

Nos encanta que se preocupen por su comunidad, por la calidad del mapa y por que los usuarios sean alertados de los peligros en la vía pero les que pedimos que, hasta que podamos dar una solución a esto, por favor corrijan y no editen más segmentos con el fin de forzar al TTS a reportar el peligro. Es importante editar siguiendo la realidad en la medida de lo posible, de lo contrario las ediciones dañan el mapa y los algoritmos de Waze de las siguientes maneras:

• Opciones de búsqueda y desempeño limitadas
• Los cambios que hagamos al sistema de TTS no funcionarán correctamente
• Problemas con el mapa
• Problemas de enrutamiento, y más daños…

Es importante que sepan que nosotros no tenemos la opción de respaldar el tipo de ediciones que están haciendo y no está dentro de las pautas del WME. Por favor tomen en cuenta este artículo en el Wiki, escrito por la comunidad, en el que menciona cuáles son las mejores prácticas de edición.

Con el fin de poder saber cuáles son las alertas permanentes que su comunidad necesita, por favor envíenos una lista de los Obstáculos Permanentes por país y en orden de importancia. Para mayor comodidad, pueden llenar este formulario.

Agradecemos su comprensión. Cualquier pregunta por favor no duden en escribir.

Saludos,
debbie y adrian

E quem disse que GC só tem que entender inglês, com o mundo globalizado espanhol também entra na pauta.

Ah… e Beijinho no ombro para o armengue passar longe…
[youtube]http://www.youtube.com/watch?v=73sbW7gjBeo[/youtube]

[antigerme]

Como usar os nomes alternativos para obter melhor aproveitamento do TTS.

A imagem do post abaixo me da um coceira… :lol: :lol: :lol:

https://www.waze.com/forum/viewtopic.php?f=212&t=109209#p896859

@MapSir

Hi All,

We received some issues from the North American community regarding wrong instructions or missing instructions during routing, specifically at junctions.

This is due to a change we applied to the algorithm in order to improve the small detours issues.
The fix included the activation of comparison of alternate street names, meaning that if two connected segments are of the same type and have the same name or alternate name the system will treat them as part of the same road and give no instruction, even if there’s a split, since it is calculated as simply continuing straight.

See example: https://www.waze.com/editor/?env=usa&lon=-122.67351&lat=45.50223&layers=1477&zoom=7&segments=41014974,62143786

(unavailable attachment: Screen Shot 2014-09-17 at 11.58.51 AM.png)

The Freeway splits into two ways, one goes right and one goes left.
There is a workaround applied in order to force the routing instructions to say “keep right” or “keep left” by making part of the left ramp a Freeway too.

This was working when we only compared road type, but since we started comparing the alternate street names too our system treats the right segment as continuing straight.

The fix for these issues is very simple, if you want to keep forcing the instructions in places like this you just need to give all the connected segments the same alternate street name.
The algorithm will treat both right and left segments as part of the same road but will be forced to give an instruction since the road “splits”.

This issue seems to be relevant to North America but may affect other countries too, depending on the mapping technics.

Thanks

https://www.waze.com/forum/viewtopic.php?f=212&t=109209#p896943

@MapSir

@top_gun_de

Hi Irad,

thanks for the heads-up. I am not yet sure if I understood it completely, but I’ll have a closer look in the evening.

However, considering your proposed workaround, I have one question:

All these workarounds should no longer be needed with the arrival of the junction box in the editor. It was shown last year in Israel as a sketch, and with screenshots in BCN. Is the implementation planned for this year? In which case I would suggest not to invest too much workpower in workarounds.

Best regards,

Detlev

Hi,

What I suggested is not a workaround, it’s a solution to the users workaround to force instructions.
We are working on a larger feature called “Big Junctions” which will help with many similar issues and turn instructions, but there is still a great importance to alternate street names since not all junctions will be suitable for the use of Big Junctions Box, meaning map editors will need to take into account the fact that we now compare alternate street names as well as road type.

I will gladly explain more if there are any questions.

https://www.waze.com/forum/viewtopic.php?f=212&t=109209#p897672

@MapSir

Hi guys,

First of all, the alternate street name comparison was part of a different fix that happens to solve a large amount of small detours that users were getting and complaining about, it’s not a workaround for your workaround.
As you know the algorithm isn’t simple and we can’t take into account all the mapping methods world wide and adjust it locally, and we’re working very hard to help you get rid of workarounds with features like the Big Junction Box.
But until this feature and others will be released we’ll have to find ways of overcoming these situations.

In this case of trying to force routing instructions you have the option to either give both roads the same alternate name, or give them no alternate name at all.
It’s not an ideal solution, but neither is using helper segments and other kinds of workarounds, we’re working on providing you with the necessary tools to edit the maps and keep in mind that applying fixes to the algorithm might cause unexpected behavior where different communities use different mapping styles.

Thanks

[antigerme]

Meio antigo mas como só me perguntaram hoje, só hoje que lembrei. :mrgreen:

https://www.waze.com/forum/viewtopic.php?f=212&t=111672&hilit=place&start=80#p944752

@shirlig

Hi guys,
In the next few days we plan to deploy an update in the places-block mechanism.
Currently, a user gets -1 point per rejection and -3 points per ‘inappropriate’ flag (that was confirmed by an editor).
As I wrote in my previous post, this logic seems to block contributing users unrightfully and therefore, we’re very lenient in the unblocking process.
To improve this, we’ve decided to leave the decision to block users to the community. Users will only be auto-blocked only if they reach -10 points due to ‘inappropriate’ flags.
If you think a user should be blocked, please add him to the user level monitor. We may add a separate tab in the spreadsheet for this process.
Once this update is complete, the support team will check with the community before un-blocking a user.
Please make sure to use this tool moderately and responsibly

Thanks,
Shirli

https://www.waze.com/forum/viewtopic.php?f=212&t=111672&p=945300&hilit=place#p945541

@shirlig

@kpouer

-3 for an inappropriate flag ? It seems hard, many times I accepted some photo that are not very good for a place because it is better than nothing, then those photo might be flagged when the place get many better photos. It is not nice in that case to block people. At least do they receive a message when they are blocked ?

A user needs to get 4 ‘inappropriate’ flags (confirmed by an editor) before they are blocked. As we have a relatively low number of confirmed flags daily, this is not something that should happen very easily.

@scarlogarcia

Thanks, Shirli.
However, brazilians won’t be able to administrate so many blocks. Would be better if it could continue automatic and you allow us to use block/unblock spreadsheet for PUs. At least in Brazil.

We cannot manage such amount of blocks at least till users get more educated about the feature after so many automatic and temporary blocks.

Why would there be so many blocks?
The current process blocks very few users daily.
For example in Brazil, the automatic process have blocked 5 users in 4 days.

@kazmuth

Not sure if this has been mentioned elsewhere but I would like to clarify something. From what I understand, being place-blocked means a wazer is only blocked from doing place updates but not blocked from editing in WME (except editing places probably).

A ‘Places-blocked’ user can not perform any action related to Places. It doesn’t block him from regular editing.

If a wazer is blocked on WME through the user level monitor spreadsheet, will that wazer also be blocked from doing place updates?

The other way around doesn’t work neither. Being blocked from editing doesn’t prevent you from adding places.

Está na hora de fazermos um script para relatar places inapropriados via WME.

[antigerme]

Regression check ativo no WME, no momento apenas dando aviso mas logo após ajustes não permitirá certos tipos de edições.

https://www.waze.com/forum/viewtopic.php?f=212&p=1166867#p1166867

@redviper26

Hey guys,

The regression tool is live in production. For those who are not sure what it is: When users will try to save actions that are potentially harmful to the map, they’ll get a warning message.

As a first step, users will be warned in one of the following cases (but will still be able to save):

Crooked segments
Intersecting segments at the same elevation with no junction between them
Routing problem - a segment can be entered but not exited
Disconnection - the segment is isolated and cannot be driven on

Thanks and your feedback is as always appreciated,

Noam

[antigerme]

Posição do Waze sobre rotas perigosas por causa da criminalidade.

https://www.waze.com/forum/viewtopic.php?f=212&t=151751&p=1177111#p1177111

@redviper26

Hey guys,

I know this is an important subject. But the fact is we can’t designate an area as dangerous just because we decided to, or even because community members say it is. In Israel Some areas are restricted by law, and we follow that law. In other countries situations like these can’t be solved by us. Our goal is to have an accurate map, representing all roads and routes, and comply with the local laws.

Thanks,

Noam

Ah… e ainda tem o problema de ser uma patente da Microsoft.

[antigerme]

Por favor, não é para sair criando junction box em tudo quanto é canto indiscriminadamente, apenas nos locais que tem problemas.

https://www.waze.com/forum/viewtopic.php?f=211&t=161985#p1227440

@MapSir

Junction Boxes - Introduction

What are Junction Boxes?

Junction boxes are basically a hint editors can give the Waze routing services. The hint, in plain english, is - “these few segments are split in a few places, but generally should be treated as a single point which switches traffic from several sources”. This hint helps the routing service get better ETA calculation and hence select better routes for Wazers.

A junction can have several inputs and several outputs - the geometry of the segments inside does not matter for ETA calculation purposes.
What kind of problems are junctions supposed to solve?

Let’s take the following area. Let’s assume all roads are two-way and all turns are enabled:
(unavailable attachment: Screen Shot 2015-10-14 at 3.41.37 PM.png)

Let’s consider the drivers going from A to E - and let’s say there’s sometimes a traffic jam for the left turn (at point D) that goes up even northern than point C (red), but the traffic from A to F is flowing just fine (blue):

(unavailable attachment: Screen Shot 2015-10-14 at 3.42.44 PM.png)

The problem with this situation is that the traffic from point A to point C is considered to be the same for both the red and the blue cars - the same statistical data is gathered and the average speed is skewing the ETA for everyone.

A junction box could solve it:

(unavailable attachment: Screen Shot 2015-10-14 at 3.43.34 PM.png)

With a junction box setup like this, historical and real time data will be collected separately for each one of the possible routes in the junction - all 12 of them. The improvements will not be felt immediately - it will take up to a few weeks for the collected data to influence the route selection and ETA algorithms.

Turn restrictions

Another key feature of junction boxes is that they can also disable turns which are enabled by default. Up until now this required adding artificial segments, or use bow-ties. Consider this example:

(unavailable attachment: Screen Shot 2015-10-14 at 3.44.24 PM.png)

The editor who built this junction cleverly decided to connected all the involved segments to the node in the middle. This was the only way to control all turns - and disallow some U-turns for example.

With junction boxes, this could have been solved in with a junction built like this:

(unavailable attachment: Screen Shot 2015-10-14 at 3.45.24 PM.png)

We can see that we can disable the A->G U-turn while still allowing the A->E left turn.

FAQ
Great! so now we can just go and draw thousands of junctions everywhere?

We would have to advise against this. Junctions are only suitable for specific locations where the above problems are experienced. Junctions do have weaknesses - more space is required to store all the data involved, and the routing services will take longer to analyse and provide routes using them.

As with any software product, bugs are possible. So at least while this feature is in it’s early steps, we would recommend refraining from using junctions in very busy and central locations.
What it looks like in the WME?

Visually in the editor, they appear as a polygon surrounding a few segments and nodes. When the polygon is selected, it exposes the connection editor in the left pane. There’s a new layer - ‘Junction boxes’, and a new tool to draw junctions which is only available for users with the correct permissions, within the ‘Add’ menu.
What will they look like in the client?

Junction boxes are not visible in the client - they are only considered by the routing server and have no visibility in the client nor in the live map. They are not searchable in the Waze search engine as well.
Who has permissions to edit Junction boxes?

For now, only users with level 5 and up have permissions to create or delete junction boxes. Any segment that has a junction box applied to it cannot be editable by anyone. If an edit is needed, the correct solution is to delete the junction, edit the segment, and then reapply the junction.

What is the deployment plan? are these available in all environments right away?

TBD
What more is planned for this feature?

The next step is adding time based restrictions to the connection editor.

[antigerme]

Pessoal,

Os editores que chegarem no mínimo requerido para lvl3 terão seus níveis automaticamente subidos pelo sistema, mesma coisa que hoje já acontece com lvl2. Claro, os que tem alguma restrição permanecerão no nível imposta pela restrição.

Lembrando, lvl2 (3k) e lv3 (25k)

https://www.waze.com/forum/viewtopic.php?f=212&t=180995&start=50#p1401028

@adriansinger

Hi guys,

Thank you for sharing your concerns. Waze Community’s commitment to the map’s quality is what keeps them so fresh and accurate.

The 80% dashboard gets updated automatically together with the user’s Save. It’ll usually have a delay of ~1 hour, but that won’t prevent you from blocking users who need to be treated separately. Just a reminder: the 80% dashboard allows you guys to monitor users way before they get to the amount of edits required to be upgraded to the next level. And with the improvements we’ve recently applied to it, you have full control over the candidates.

We encourage you to review your lists (if you wish to do so) before and after Sunday, May 15. That day, as said, we’ll activate the automatic rank upgrade to Level 3.

We understand your concerns about new Level 3 editors having the power to potentially damage the map. The community will never be 100% free of cheaters and abusers, but they need to be dealt with separately with the power of veto that you all have.

As previously explained, we have launched all the tools necessary to help make community growth a scalable task, while keeping the map protected:

Throttling system
Regression Checker
Editor Profile
80% Dashboard
Automatic Road Rank Blocking
Community Action Requests
WME Feed with PMs

Additionally, we are investing in communication tools inside of the Editor and user education:

Conversation on URs
Live chat (under improvement)
Map Discussions planned
Monthly Intro to Map Editing Webinars
MapRaids
Wazeopedia

Future plans include working with the Product team to add the upgrading flow to the Editor itself (instead of external spreadsheets).

Specifically about the 80% dashboard, these are the improvements we’ve made, following your suggestions:

More users appear on one page (by default)
Filter on any column (excluding dates). Ex: Easily get a list of all editors eligible to rank 3 from Germany, and then sort it by any criteria.
Changed username link to the editor profile, instead of user’s forum page
Added column for states

(unavailable attachment: dash111.jpg)
(unavailable attachment: dash2222.jpg)

As said before, the intention of this thread was not to put the responsibility of rank delay on the community, but rather to show an issue with the scalability of the process with the existing restraints of the WME.

We agree that improvements need to be made on the process to automatically identify good editors. We want to find the right balance between quantity and quality, and we’re going to address this issue, too.

If you have more questions or concerns, I’ll be happy to read them here.

Thank you!
Adrian

https://www.waze.com/forum/viewtopic.php?f=212&p=1405267#p1405267

@adriansinger

Hi guys,

As said two and a half years ago, we’ve been working to automatically upgrade good editors between levels 1-3. This includes improving the map protection mechanisms and the development of the 80% dashboard to make sure no problematic editors are upgraded and no damage is made to the map. Manual upgrades for low levels is not scalable, the path is not globally consistent and editors who want to advance have no clear rules or action items for that.

Please allow me to quote Shirli’s post from January 2014:

@shirlig

We are aware of the fact that some of the local communities prefer working with their own set of rules and have exclusivity on editors’ progress decisions.
We want to allow some independency for communities who want to have local rules, however, please note that there are official rules for ranking up and we want to be as consistent as possible towards the users.
Please make sure to use the user level monitor to mark users who don’t follow the guidelines, abusers, cheaters, sloppy editors, etc.
Please don’t use it to adjust the permissions level to a different progress flow.

The 80% dashboard is not only an excellent tool to control who is upgraded and who isn’t, but also a great source for you to discover new editors. We encourage you to use it to meet editors who are about to be upgraded and mentor them. If they are problematic editors, you can always block or lock their permissions. Unjustified blocking/locking requests will not be approved.

As said at the beginning of this thread, we want these editors to keep active and motivated, instead of feeling stuck and left outside. One of the reasons users wait so long is their lack of awareness of the need to contact their local community. And as explained previously, we’ll tackle this issue too. We want users to have an easier way to meet the community and understand local rules. Meanwhile, you guys can use the 80% dashboard to bring good editors into the community, and block the problematic ones. If you look at the amount of candidates in your countries, and if you check the dashboard a couple of days a week, you’ll find that this is definitely manageable. Please also avoid increasing the segment locks unless absolutely necessary, as this will frustrate good editors who want to contribute to the community.

In conclusion: With the new system, candidates will surface easier and instead of them having to contact you, you’ll have the chance to exercise your leadership and contact them. Are they good editors? Let them continue with the automatic upgrade. Are they making problematic edits and not responding to your messages? Block them.

Last but not least: We’ve seen comments here referring to the staff “beating” the Community (“kick the community eyes”), or getting counsel from political parties. These kind of comments are disrespectful and they don’t contribute to the discussion. Basically, they violate the Waze Community Communications Guidelines. Please avoid them as we want to keep a rational conversation in a friendly environment.

Thank you,
Adrian

https://www.waze.com/forum/viewtopic.php?f=212&t=180995&p=1409172#p1409983

@shirlig

Hi guys,
I’ve been following this thread very closely and read through all the concerns you brought up. I’d love to share with you my thoughts on this new change and hope it helps you feel more confident about it.

First off, I want to emphasize that the new automation does not take the control over editors’ progress from the community’s hands. The community has all the information about the level-upgrade candidate before they are promoted and the tools to stop their promotion, if needed.

This new process should actually simplify things - and I think that once you try it, you’ll see the benefit to both new editors and community leaders.

As karlcr9911 said:

@karlcr9911

We’re now able to more easily find editors we didn’t know about before (…) and reach out to them more quickly before they auto-promote

A scalable process allows all editors a clear path to reach level upgrades.
Here’s how I see it:

If your community has a method of knowing all your area editors - and you are therefore able to guarantee that those who should be promoted are promoted, and those who shouldn’t are locked - then there’s nothing in the automation that is worrisome.

If this is not the case - and you are not aware of all the editors - you may be unaware of bad editors who quietly gain editing points and damage the map. At the same time, you might be missing some good editors, who are willing to contribute and need your help to do it in an appropriate manner.

This new process provides the tools to assure that community leaders know the newbies, and that an editor’s progress is closely monitored.

We agree that adding notifications for new users to the 80% dashboard would be good. However, we checked with the devs and it’s technically not doable at this time. However, filtered by country and rank - I’m sure you’ll realize that the lists are a reasonable size.

I hope this clarifies our stance and allows us to move forward in a positive way.
We’ll be sure to keep an eye on this issue and feel free to share your continued feedback.

Thanks,
Shirli

PS.: talvez teremos liberação automática também para outros níveis, só depende de como a comunidade irá se comportar.

[antigerme]

https://www.waze.com/forum/viewtopic.php?f=211&t=161985&p=1475426#p1475426

@MapSir

Hi All,

This is an official announcement to inform you any user who is caught using the word “soon” will be reverted to waze version 2.0

Alright seriously, I’m checking when JB’s will be released. Thanks guys.

:lol: :lol: :lol: