[OSM-talk-fr] JOSM et validation rule : bug avec regexp_match ? — Re: Nettoyage des clés mapillary

[Yves P.]

Bonjour,

> Le 3 nov. 2019, PanierAvide  a écrit :
> 
> Sur le modèle du fichier MapCSS pour les tags Wikimedia, on peut ajouter une règle avec un "regexp_match" pour rechercher/remplacer automatiquement. Pour une raison qui m'échappe, la règle suivante qui devrait faire le boulot ne fonctionne pas (pour tester, créer un nœud avec le tag mapillary=https://www.mapillary.com/app/?lat=49.18298900000002&lng=-2.1090169999999944&z=17&pKey=XCcwknc5F9zgqs6GKBUFig <https://www.mapillary.com/app/?lat=49.18298900000002&lng=-2.1090169999999944&z=17&pKey=XCcwknc5F9zgqs6GKBUFig> ) :
> 
> *[mapillary][mapillary!~/^[a-zA-Z0-9_-]{22}$/][mapillary=~/pKey=[a-zA-Z0-9_-]{22}/] {
>     throwError: tr("mapillary tag should only contain image ID instead of full URL");
>     fixAdd: concat("mapillary=", get(regexp_match("pKey=([a-zA-Z0-9_-]{22})", tag("mapillary")),1));
> }
> 
> Si un expert JOSM/MapCSS peut nous éclairer là-dessus... :-)
> 
> 
En fait, c’est comme si il manquait le flag « g ».
L’expression « pKey=(.*) » ne fonctionne pas, mais « .*pKey=(.*).* » oui !!

La doc <https://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation> parle de flag i, m ou s.
Flags is a string that may contain "i" (case insensitive), "m" (multiline) and "s" ("dot all »)
Idem pour Javadoc <https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/mappaint/mapcss/Functions.html#regexp_match-java.lang.String-java.lang.String-java.lang.String->

Il y a plus de flags décrit ici <https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/mappaint/mapcss/Functions.html#regexp_match-java.lang.String-java.lang.String-java.lang.String-> : 
flags - Match flags, a bit mask that may include CASE_INSENSITIVE <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#CASE_INSENSITIVE>, MULTILINE <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#MULTILINE>, DOTALL <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#DOTALL>, UNICODE_CASE <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#UNICODE_CASE>, CANON_EQ <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#CANON_EQ>, UNIX_LINES <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#UNIX_LINES>, LITERAL <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#LITERAL>, UNICODE_CHARACTER_CLASS <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#UNICODE_CHARACTER_CLASS> and COMMENTS <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html#COMMENTS>
Le flag g de Perl est implicite d’après la doc :
Perl uses the g flag to request a match that resumes where the last match left off. This functionality is provided implicitly by the Matcher <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html> class: Repeated invocations of the find <https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html#find--> method will resume where the last match left off, unless the matcher is reset.

C’est comme si l’expression régulière était évaluée différemment par regexp_match et MapCSS ??

—
Yves

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20191105/0e63b96f/attachment.htm>