@Dmitriy.Sorokin
This problem has been around for so many years, when will it be solved
@lsl unfortunately Evgeniy.Timofeev doesn’t work in Aspose.GIS, so, if it suitable for you, could you please provide expected code sample for your task.
Can you view the history of this post, so you understand what I’m saying?
@lsl we need to review roadmap, so, we wanted to focus on the must-have features for customers. At this point, your assistance would be appreciated. If you have requests and have the vision of how this should work, could you please specify the most important features for you?
These requirements are very common, you can refer to ArcGIS for sure. For us, what we need is layer information modification, field information modification
Update to the original data instead of rewriting all records to the new file after only one change (after all, a gdb may have several gigabytes, and you only changed one record)
other feature： layer with layer topology, layer with feature topology
@lsl
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies. Your request added with high priority.
Issue ID(s): GISNET-1639
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Hello, I am from Aspose.GIS. Regarding the topology, am I correct in assuming that you’ve already familiarized yourself with the classes/functionality of the Aspose.Gis.Topology namespace and nothing suited you there ?
These are basically sufficient
esri gdb / shapefile “InFIleEdit” is very important for us @roman.charnashei
@lsl Yes, of course we’re busy finding the right solution for you right now regarding esri gdb. Basically we try to stick to stateless, functional approach which helps to keep the architecture cleaner and more maintainable. In the case of modifications, it will take time to revise the architecture.
Also I’d like to ask more details about topology. Do you mean that this is basically enough for your purposes and tasks or is it only enough for a limited number of functionalities and you would like to expand them ? If you want to expand it, please tell us what features and characteristics a topological layer should have, what is important for your tasks ?
For us, the current topology functionality is already sufficient, while the rest are some encapsulation within our own field. We usually use ESRI products more often, and you also know ESRI’s reputation in the GIS industry. It would be best if your interface could align with them.
At present, the most important thing for us is to support “InFileEdit”, of course, while implementing the function, their read and write performance should not be too poor
Hi, @lsl
We are going to make new API for gdbtable file to update feature (by index), add new feature at the end of file and remove feature (by index). After every action the gdbtable file will be save but not rewriting all records. Will it useful for you?
By the way we have “Edit” mode where you can do any action with gdbtable file many times and then save it (but in this case we rewrite all records)
add new feature at the end of file and remove feature (by index).
When deleting, only the index was removed, right？Will this cause the files to become larger and larger, as sqlite databases need to be compressed
These sound good. I have a suggestion for you to use a large GDB test with multiple layers, each with millions of records, internal testing for crud and performance comparison with ArcGIS and GDAL
Hi, @lsl
Thanks for your ideas, i will check it.
This task in debug and testing now.
It will be in july realese.
Hi, @lsl
We override “Edit” mode for .gdbtable file. So, now you can update feature, add new feature at the end of file and remove feature (by index) without rewriting all records.
Check it out in july realese.