Verdy_p has commented on the following diary entries

Post When Comment
Géocodage d'établissements scolaires 2 months ago

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)

Géocodage d'établissements scolaires 2 months ago

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).

OSMF Selling Data to Google? 8 months ago

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).

Monthly roundup - common errors and unexplained edits observed 10 months ago

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.

Yet another noname layer ... about 5 years ago

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=" !!!

Message couldn't load map over 6 years ago

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....