Priority 2: Class conflict lors du merge du land cover

[SteeveEbener]

j'ai fait un test pour voir si le merge land cover identifiait effectivement les conflict de classes (j'ai créé une couche de route avec les même classes que celle du landcover) et l'identification ne s'est pas faite, il n'y a eu aucun message ni d'information reportée sous stack category conflict

Frédéric: contrôle des conflit. Ok, je vais tester avec d'autres données.

[fxi]

The conflict process was rewritten. Please check and send a feedback. Thanks

[SteeveEbener]

Je viens de comprendre que tu devais régler le premier conflit avant que le deuxième n'apparaisse.

Cependant, le système me permet d'utiliser une nouvelle classe qui existe également déjà sans pour autant identifier le nouveau conflit que cela génère

Autre problème que je viens de noter, la colonne contenant la "class" à sélectionner sous "Add roads to stack" est par défault "New_class" et non pas une des colonnes de la table d'attribut d'origine.

Au vue de ce qui précède, et vue que l'on ne peut pas implémenter ce qui est fait dans la version 4, j'en reviens à l'idée de simplement demander à l'utilisateur de changer les classes dans la table d'attribut de la couche d'origine avant de lancer le merge du stack où alors de présenter la table des conflits différemment afin que l'utilisateur puisse avoir tous les records devant les yeux au moment de faire les changements.

[fxi]

As requested by mail, please send me some data for testing this issue.

[SteeveEbener]

I have put the data in question under: AccessMod5\data\sample\MWI_conflict_roads in the dropbox. The shape file presenting the same road classes than the landcover is named: Roads_conflict.

You can actually create similar shape file for other datasets by reclassifying the class of the original road network layer.

[fxi]

There was an error in regex/grep command. Please check if this issue is resolved.

[fxi]

-A conflict of class will now block the merging process. -For the "New_class" , this is not part of AccessMod 5 code. Check again your attribute table and open a new issues for this. -I Did not found your dataset MWI_conflict_roads in dropbox.

[fxi]

This issue is NOT resolved, why did you closed it and reopen a new one ? This is NOT productive. I did NOT received your dataset to test at the time i've asked you to check, please be cooperative. If there is a problem with a particular dataset that I don't have, I need to check why this dataset is problematic.

[fxi]

I've checked with the dataset you provided. This is not a problem of conflict logic. Only one type of road are kept stack if all have the same data name ! road [main] == road [main]. Stack item are not reusable item, they are temporary data that we can overwrite. I've put a validation step to prevent the user to create a stack containing duplicated name. I will update this thread after testing.

[fxi]

I've tested with the data you provided. I did not implement this level of foolproofing, sorry. The road labels are the same for all road class. And this is visible in the table, you can't ignore it. But I've implemented a validation process to handle this very special case. Thanks.

[SteeveEbener]

Sorry if I misunderstood you but one of your previous comment as well as the following email was mentioning to close the issue and open a new one:

From: Frédéric Moser [mailto:frederic.moser@unepgrid.ch] Sent: Friday, June 19, 2015 9:30 PM To: Steeve Ebener Subject: Re: FW: [AccessMod_shiny] Class conflict lors du merge du land cover (#19)

Le dataset est apparu dans la dropbox, mais c'est pas encore complètement téléchargé.

Cela dit, j'ai effectué un test avec des erreurs de classes avec un autre dataset (philippines 500m) et j'ai réussi à reproduire le problème. J'avais fait une erreur de syntaxe d'expression régulière, ce qui empêchait certaine couche d'être évaluée pour la détection de conflit. Ca devrait être réglé maintenant. Si c'est le cas, tu peux simplement fermer le ticket dans github ou donner de nouveaux détail.

Merci,

Fred

I am therefore copying here the new issue you closed in order to keep the all track:

The resolution of class conflicts between the road network and the landcover is still not working.

This morning I have used the conflict road and landcover layers I placed in the AccessMod5\data\sample\MWI_conflict_roads folder in the dropbox.

Both files present the same set of classes: 1, 2 and 3 but he only asked me to solve the conflict for class 3 and did the merge keeping the other two conflicts and therefore removing some of the roads

In addition to that, I thought the "new_class" column would be physically added to the original road layer to be able knowing the correspondence with the original class but it seems this is not the case.

Finally, if you have to set of roads in the stack, which can be the case if you want to look at the impact of building a road (case currently discussed with ADB) the module identifies conflicts among road layers as well.

I am sorry but this approach for trying to solve the conflicts is too complicated => we need to reach something that is much closer than what is implemented in Version 4.0.

There are reasons why we have been using this approach, even since the first version of AccessMod if I am not wrong.

Thanks for your understanding,

Steeve

[SteeveEbener]

I have done the same test this morning after having updated AccessMod to revision 213 and the problem is still the same than in the issue you closed.

The identification of conflicts between roads happens when using different set of roads (not the same tag) and the module does not identify all the conflicts between a landcover and a road network presenting the same classes.

Once more this approach is too complicated and we are loosing too much time on this while the one we have used since the 2002 works => This time I am kindly requesting for this approach to be changed to the one used in version 4.0, meaning:

• 1000 is automatically added to the road classes
• the "class conflict among items in the stack" section in the window be replaced by a table that allows visualize the final content of the attribute table after the merge

This change is going to be a condition set for me to accept the release of AccessMod.

Thanks in advance,

Steeve

[fxi]

1. In the email you copied in this public repository, I asked you to close this issue if it was resolved, which was not the case, as the updated code did not work with the special case you created. This is not a big deal. I understand that this issues manager is quite new for you.
2. That's impossible that the problem remains the same, with the data you provided, as the road stack creation process will not allow duplicated labels or classes.
3. This feature could be available for advanced mode, as it appears to be quite challenging for a non expert user. The default function for the road will be implemented as you described: add 1000 to road class. I agree with the opinion that's the easiest way to solve this particular case. But keep in mind that conflicts could be more complicated if you add another set of roads or another land cover (E.g. partial land cover). This tool enables the user to add as many layers he needs. We have to handle this new complexity with a flexible tool.

Thanks for your comments, I keep you updated as soon as I have implemented the road stacks management.

[SteeveEbener]

All good now on the 3 points. I don't know why point 2 was not working before.

In any case it is good to keep this approach for the advanced mode as the possibility to mix several roads and landcover type requires quite some understanding and focus from the user.

Just one small thing, when you have 3 pairs of conflicts the warning message says that there are 6 conflicts. Would it not be more correct to say that you have 3 conflicts in this case?

It would make sense according to me as when you change one class only the number of conflicts comes down to 4.

[fxi]

We count now the number of duplicate. This is ok for you ?

[SteeveEbener]

Perfect thanks