Thanks for sending the Shapefile.
I can see that you’ve mapped feature IDs to your
Line_Numb Shapefile attribute which is zero for all your features, but GPlates requires feature IDs to be unique. This is because when the topology looks for a boundary section with feature ID
0 it will find more than one. This results in ambiguity so it chooses neither (this way it becomes more obvious that the topology is broken, rather than taking the risk of arbitrarily choosing a boundary section which could the wrong one).
I would suggest mapping your
Blocs.shp again (you might need to delete the
Blocs.shp.gplates.xml file to clear the current mapping) and load
Blocs.shp back into GPlates again and map like this…
Feature ID: is left as
Then save it as
Blocs.gpml. I know you’re not doing this, but for others if you keep loading the Shapefile (instead of GPML) then GPlates will create new feature IDs each time you load, and the topologies will not be able to find those features. This is something we need to look into when we overhaul our non-native file IO (eg, maybe we’ll create a new Shapefile attribute to store the feature ID in).
Then you can create topologies (unfortunately you’ll need to create them again).
Alternatively you could map
Feature ID: to a Shapefile attribute that you know will be unique across all your features. But generally the feature ID should follow the string format that GPlates gives it (which starts with
GPlates- and has alphanumeric characters and
. only). It’s best to allow GPlates to provide the feature ID (which it will do if you leave it mapped as
<none>). And, as you have correctly done, we always recommend using GPML format when working with topologies (both the topologies and their referenced sections).