No, the “Belgian” mailing list is not the correct place to summarize, just like any one of the many mailing lists that OSM has because no one will ever subscribe to all of them or would have to support many mlessages in a language they can’t read or write.

Even the English (only) general OSM mailing list is the bad place : it excludes many users from discussing.

The OSM forum also is not suitable (and in fact it is closed by a few users appying their own local policies they have enforced without any discussion).

Only one place allows summarizing : the wiki, it is really international and allows linking to all relevant places (mailing lists, blogs…) where things are published. And where things can be reviewed later at any time by anyone (without also having to constantly monitor everything as they happen: it can be reached and discovered later, it is archived).

But it does not mean that every thing must be hosted on the wiki, it is just a central repository to post the links and summaries, and inform others when things are occuring somewhere (people need to be informed that a decision is taking place somewhere, but unfortunately most important decisions are taken that have long term impact and on more people than those that were connected to the specific channel, without informing anyone outside, and then it’s taken as “decided”, even if few people participated. It also excludes any newcomer from having their own view, and does not allow reviewing the past “decisions”).

For this reason, the wiki should be mor eprecisely managed and structured. However most people don’t care about linking and categorizing what they post there. And many OSMers think it is not important to do that: I disagree, without the wiki the OSM community would not exist at all internationaly, and OSM would not be an international project, and we would not even have the various tools we have now to structure the data and audit its quality. It is the essential part of OSM: documenting what is existing now, what will happen, what may change, problems encountered, solutions proposed, solutions abandonned (yes this happens but too rarely), and policies (where they can be also reviewed later to improve or remove them when needed).

Email is NOT too old, they are easily manageable and sortable like people want (not the case with forums). They are archivable unlike IRC which is lost: any decision or talk in IRC is immediately lost and IRC should never be used for discussing issues prior to deciding something. Forums are nightmares to navigate and search and their content is deleted/moved without notice. However we also have too many lists and users cannot track all of them and will not want to subscribe all of them. Additionally some miling lists are targetting specific languages and are very geographically centered, meaning that they will not be accessible to many users that can’t participate to the decisions. There are different ways to communicate but at least the wiki is the central point to collect the result and inform other people of what is going on in specific communication channels: all important discussions and decisions should be documented and summarized on the wiki even if it is just to include an URL to some publicly readable archive, website, or blog.

All past decisions must be motivated with a track of talks and votes that occured (which most of the time involved only a few users, and not the general community at large) and with ways to know who to contact again: all past decisions will need to be reviewed later by others having different opinions or new needs or problems to solve that were ignored in the past decision.

I personnally consider that ANY decision made in a specific communication channel and which was not publicly announced and tracked on the wiki as INVALID, and UNJUSTIFIED: this decision only affects the effective participants of these specific channels (and only at the time they used it: IRC for example is an extremely bad channel for collective decision process because we cannot ask to everyone in the OSM community to be online there 24/24-7-7 to follow what happens).

The same is true about social networks (notably Facebook, Twitter) because they are inundated by floods of unrelated posts or reposts from various pages and it’s simply impossible to follow everything that happened there (and notably months or years ago). These are “junk” channels, almost immediately forgotten.

If every community was correctly communicating, it would document the channels they use on their local wiki page. And would report there also pointers to important transcripts, and talks that happened. Otherwise it’s not possible to track all the various channels that are used. And what was an early consensus would probably no logner be the case with current users (also users should know that they are not mapping for them alone, in their own local place, and users will be interested from around the world, and will want to use the data un unexpected ways: this is the goal of OSM to open the data to more people, wherever they are, and whatever language they use). The communication channels are changeable at any time, but no decision made locally in these channels should be considered valid if they are not centralized and summarized in a central place where they can be found… and later contested to create something better and more reusable in more contexts than those initially considered.

Je sais très bien que UMap peut lire les requêtes Overpass, ce n’est pas la question. Ici je commentais le fait que “extent”:[x1,y1,x2,y2] ne correspond à rien dans UMap, c’est une bounding box, pas une géométrie représentable. UMap détermine lui même les bounding box pour déterminer un niveau de zoom par défaut. Mais il ne sait pas quoi faire d’une propriété qui ne serait pas une “string” en valeur ou une valeur numérique : y mettre un tableau (JSON) ne donne rien, la propriété est ignorée et OSM ne permet pas de coder des tableaux de données en valeurs, et si on y met du JSON, ce sera une “string” (limitée à 255 caractères) et ce n’est pas une valeur d’attribut OSM standard. Note que par Overpass on n’obtiendra que les attributs des objets codés dans les “properties” d’un objet “Feature” geoJSON. Overpass cependant peut aussi retourner des données en format OSM-JSON qui n’est PAS le geoJSON (format très différent notamment pour les relations inexistantes en geoJSON, et la représentation des surfaces, geoJSON ne décomposant pas les ways et surfaces pour leur associer les noeuds membres et n’identifiant pas les noeuds fusionnés, les géométries GeoJSON sont totalement autonomes et reliées à rien d’autre que le “Feature” qui inclue chaque géométrie)

La conversion en CSV n’est pas nécessaire pour uMap qui peut lire les GeoJSON directement avec les propriétés incluses dans chaque “Feature” importé dans la collection “FeatureCollection”.

Dans uMap tu trouves ces propriétés directement dans les champs “avancés”, sous lors forme “type”:”valeur”. Cependant “extent”:[x1,y1,x2,y2] n’est pas utilisable directement. Et il te permet d’utiliser ces champs de propriété aussi dans la mise en forme de la description. Tu peux aussi utiliser un ou plusieurs des champs pour le tri automatique. Le JSON peut être téléchargé directement depuis son producteur avec l’URL de sa requête sans avoir à l’importer dans uMap. uMap sait aussi utiliser la “geometry” indiquée dans un des types supportés : “Node”, “LineString” pour une courbe continue / ou “MultiLineString” pour les courbes discontinues ou maillées, “Polygon” pour une surface délimitée par un contour externe (éventuellement avec des trous délimités aussi par des contour fermés), ou “MultiPolygon” pour plusieurs surfaces disjointes (chacune avec ou sans trous).

I also agree that nothing forbids Google supporting out project by giving money, but it won’t be for a commercial contract wiht exclusive rights. It will be like other donations, only because Google supports out common project, but it won’t take more advantage than other OSM contributors.

As well Google may join the OSM foundation, like any other members, if it agrees with the existing membership status and terms.

Google can also help us develop applications, or can also contribute by offering hardware servers, or hosting (with a long enough contract warrantied for at least a couple of years, and renewed at least one year in advance).

Google also has the right to use our data, provided it gives correct attribution. Google can also develop its own renderer (but will have problkems if its renderer mixes our open data with the proprietary data protected by Google or by tits contractual providers;

What is said here about Google remains equally true for Apple, Microsoft/Bing/Yahoo, Facebook, or other large non-US companies like Vodafone, Orange or any foreign government, or any NGO…

Also true for Baidu and other P.R.Chinese (the problem with Baidu is about geographic data in P.R. China itself, except Hong Kong/Macau/Taiwan, where accurate WGS84 data is legally forbidden and has to be replaced by the Chinese proprietary “devil’s transform” when GPS/WGS84 coordinates are transformed using non-linear equations that are not easily reversible… But Baidu has a separate service in mainland China and elsewhere, just like most other international companies selling cartographic services and GPS devices (also modified in China to use crypotographically modified coordinates, that are not completley interoperable with the rest of the world).

Note that the conversion from GPS/WGS84 to the Chinese projection is extremely easy (so worldwide maps can be easily produced in the Chinese projection, but the reverse is not so easy (and legally forbidden) to produce accurate maps of China in our common WGS84 projection or other international cartographic or geodesic transforms. But this transform is not unique: different Chinese providers generate different pseudo-randomized coordinates and it seems that the Chinese “devil’s transform” includes specific parameters for authorized sellers of solutions, so these Chinese transforms are not interoperable and form a set of multiple closed proprietary systems (where also the Chinese government authorization includes an exclusive rights for Chiense authorities to force the solution providers to alter or remove any data that Chinese authorities don’t like in the data made legally available on mainland China.

So in OSM we have no way to generate accurate map, we can only produce approximations and we cannot get legal support from local Chinese contributors (including foreign people visiting China which can be jailed or fined by Chinese courts, or ejected manu-military from the country). This does not concern only Chinese companies but even Apple, Google, Microsoft and others have accepted to follow the Chinese rules in the services they offer in mainlnad China, which are necessarily diferent from those in the rest of the world: we cannot accept theese rules in OSM because we cannot given primary provileges to the Chinese government over the rest of the worldwide OSM community. As well we cannot accept that OSM would get the (costly) licence for using the “devil’s” transform required by Chinese authorities.

This does not mean that we cannot map China, but that the precision of data we can bring in OSM for that territory will remain severaly limited (with exact locations unknown with errors ranging up to 700 meters away and no way to synchronnize them with different contributors)

If we want to provide a map for Chinese users, this cannot be done with a local OSM chapter in Hong Kong/Macau/Taiwan, but we would need a specific “chapter” in Beijing/Shangai to support and generate a derived database using the Chinese transform, but that database will be constantly subject ot alterations and removals by Chinese authorities and we won’t be able to reuse these derived data, so that chapter would not conform to our rules. It’s simply impossible to accept such chapter (we can only accept chapters in HongKong/Macau/Taiwan working with international standard projections for correctly mapping their local territory, but not mainland China).

Reverting/deleting an newly added water pond which is clearly existing on the imagery (when your comment above and in the reverting changeset) says the opposite, is not the correct way to do.

I don’t know how you can check that remotely or which kind of imagery you used to revert these additions: the added ponds are present in SEVERAL imagery sources and they also match with terrain elevation data and surrounding water drains.

Many rural roads don’t have any assigned name (may be they are colloquially named in one area by saying “road of City-X” or “road of City-Y” but the choice of the city has no formal agreement. In addition this name will vary depending on the direction (even if this is a bidirectional road without separation), depending from where you start.

Instead, these roads have a national or regional numeric reference (this is the case in France where NoName ‘'’incorrectly’’’ signals “no name” despite this is definitely not an error.

Sometimes they may have informal names, used for commercial purpose (e.g. “route du vin”, “route du meuble”) or hultural and historical names (e.g. “route de la liberté”, which very frequently colloquially references a long series of distinct roads with distinct statuses) and it is not consistant and NOT used in addresses (which will instead use names of localities (e.g. for hamlets), and more rarely the numeric reference.

You should not signal roads that have a correct “ref=*” (e.g. ref=”D 637” in France): the reference is really enough (the directions that appear on road indicators indicate various distant cities according to the direction, NOT the name of the road, but they consistantly display the national/regional/local classification, depending on the local collectivities that manage it, as a letter and the numeric reference).

In France, we use Osmose, which already does a pretty good job in detecting roads missing references (and or streets in cities), and which perform many additional checks that your tool do not perform.

So most of the red colors that appear in France are completely wrong: they do not indicate a low level of advancement. I think this is also the case in most countries of Europe : we should NEVER add in OSM “fancy” road names (or descriptive names), just to avoid your “red” colors you assign to them. (If you need to add a descriptive name just tag “description=”, NOT “name=” !!!

Potlatch, qui utilise abondamment Javascript dans le navigateur, ne peut gérer autant de données que JOSM. Les modifications apportées doivent être sauvées souvent car il ne peut pas charger une quantité importante de tuiles, et par défaut tente de charger tous les noeuds, tous les chemins et polygones, et toutes les propriétés. Rapidement c'est le navigateur qui refuse d'aller plus loin en limitant la mémoire.
Avec Potlatch, on ne peut éditer des zones aussi étendues qu'avec JOSM.
JOSM est un peu plus difficile au départ à utiliser que Potlatch, mais son installation est ultrasimple (il faut toutefois avoir d'abord installé le runtime Java d'Oracle, puis télécharger un petit fichier pour JavaWebStart, dont on peut créer un raccourci sur le bureau. Un cic sur l'icone et ils se lance en téléchargeant automatiquement la dernière mise à jour.
JOSM permet aussi de faire des modifications plus compliquées qu'on n'arrive pas à faire aussi bien sur Potlatch, notamment grace au support de calques permettant de sous-sélectionner des ensembles plus réduits de données, et de choisir son modèle de fond de carte (imagerie) et de rendu. Il permet aussi des recherches, divers tests de cohérence pour la validation des données (les oublis sont faciles avec des noeuds vierges posés en trop), il peut aussi télécharger des verions historiques (utile en cas de catastrophe), ou d'essayer une modification longue dans un calque, de sauvegarder localement son travail en court, et de pouvoir travailler sur des jeux de données ou sous-cartes différentsn en parallèle, avant de les fusionner dans un calque courant qu'on peut alors valider, tout en laissant le reste à plus tard. C'est partique pour procéder par étapes, et ne rien perdre, sans casser trop la cartographie modifiée postée en ligne. Il permet aussi de ne pas envoyer les modifs tout de suite (CTRL+S pour sauvegarder le calque courant dans on fichier .os. JOSM a aussi un cache plus efficace et plus économique et rapide que Potlatch.
J'aiutilisé Jotlatch pour débuter de toutes petites modifications locales (déplacer un noeud, une voie, ou corriger un bâtiment et les croisements de routes et la signalisation, ou encore poser des POIs pour commerces/cafés/services publics....