WEBVTT 00:00.000 --> 00:17.760 So hello everyone, the sound okay here. Yeah, so I have a sort of a three-release project 00:17.760 --> 00:21.880 that I sort of want to drum up some interest for, get some early feedback on, and it's 00:21.880 --> 00:26.320 called postcat. I've got a terrible sort of self-drawn logo there, but I just wanted to 00:26.320 --> 00:32.520 get something started with that. So quick bio about me, yeah, freecat, I would say this 00:32.520 --> 00:36.640 is my main work as dependencies distribution and infrastructure. I'm also a member of the 00:36.640 --> 00:41.200 FPA, I'm a devine developer, and then sort of my educational background there, biological 00:41.200 --> 00:47.080 and agricultural engineering, and then I'm about to finish up my masters and see yes. 00:47.080 --> 00:51.480 And so this talk is a little tricky to calibrate, because I don't think there are very 00:51.480 --> 00:55.520 many people who are in the center of this and in diagram, really the only kind of need to 00:55.520 --> 01:01.480 note the CAD and databases aspect, but I am using a motivating example from the world of geospatial 01:01.480 --> 01:06.040 software, specifically QGIS, and so if anyone kind of already has any familiarity with 01:06.040 --> 01:12.600 that that helps, but I will try to make it not so necessary, it's much far. And so for 01:12.600 --> 01:17.600 anyone who's not super familiar with OpenCastCade, so it's what's used by freecat for sort 01:17.600 --> 01:24.920 of its CAD, geometry, operations, and data, and so forth. But it's got several problems, 01:24.920 --> 01:30.960 it's sort of a behemoth, it's got sort of its own C++, say, they're on smart pointers and 01:30.960 --> 01:34.720 so forth before that became a standard, and so there's just difficulty in contributing 01:34.720 --> 01:40.560 to it. But essentially, if we get more people using it, it'll benefit us all, because 01:40.560 --> 01:44.240 as soon as a developer starts using it, that's the first step on the path to potentially 01:44.240 --> 01:48.400 becoming a contributor. And even if they can't, let's say, for example, fix the sort 01:48.400 --> 01:52.880 of the holy grail problem of like the fillet operation, for example, which is very, very 01:52.880 --> 01:58.320 buggy, even if they can't do that, they can potentially free up another person by contributing. 01:58.320 --> 02:02.800 And so essentially, if we can sort of plant a seed and then grow an ecosystem, it should 02:02.800 --> 02:11.200 help us all. And so there's several ways people are using OpenCastCade already, besides 02:11.280 --> 02:16.960 freecat, and of course, keycat as well. And so you can think of it in terms of, at the language 02:16.960 --> 02:22.720 level, so people are using Python bindings, or JavaScript bindings, and so forth. But in this 02:22.720 --> 02:28.320 case, I'm actually proposing sort of an architectural, a switch in sort of the architecture 02:28.320 --> 02:35.280 and how you can interact with it by putting OpenCastCade in the database. And so this is one 02:35.280 --> 02:38.960 of my favorite things about open source and free software, is just that we can essentially 02:39.040 --> 02:44.320 pull this one and go and look at what people in QGIS are doing and say, this looks pretty cool, 02:44.320 --> 02:49.920 let's just copy everything. And so I'm going to essentially run through what they're doing with it 02:49.920 --> 02:54.560 and kind of explain postGIS, which is the inspiration for postcat. 02:59.920 --> 03:05.920 And so just to begin with, if anyone has used QGIS before on the left side of the screen, sort of 03:05.920 --> 03:10.640 where freecat has its model tree, they instead have sort of this browser here. And so you can see 03:10.640 --> 03:15.920 you've got, you know, your file system and so forth, but then you also have postGIS specifically 03:15.920 --> 03:21.280 and then potentially other databases. Since once the postGIS came around, even like let's say 03:21.280 --> 03:27.040 spatialite, they decided, okay, let's kind of take this idea and spread it throughout the whole 03:27.040 --> 03:32.400 database world. And so we can have, you know, file based databases for GIS and so forth, not just 03:33.360 --> 03:41.040 a heavy server process. And so QGIS is sort of how I first learned about postGIS, but there's a 03:41.040 --> 03:46.960 whole ecosystem around it, specifically we've got like the leaflet GIS for making web apps. You've 03:46.960 --> 03:53.840 got geojango if you just want to make, like, let's say an API and even like a flask if you just want 03:53.840 --> 03:57.680 to have something very small and simple and there's lots of other sort of integrations, there's 03:57.680 --> 04:03.840 a whole ecosystem there. And so just to kind of give you a specific example, this text small, 04:03.840 --> 04:08.480 but this kind of shows you exactly how one might use postGIS. And so in the first section here, 04:08.480 --> 04:14.160 we have a query, we are doing sort of a little bit of normal SQL where we do like select name, 04:14.160 --> 04:19.120 but then we have this sort of special function here, STS text and then we have the geometry. 04:19.120 --> 04:24.720 And so the output there is essentially this string representation of the postGIS data type 04:24.800 --> 04:34.240 showing you the latitude and the longitude there. And so you can also, yeah, so here's another 04:34.240 --> 04:38.160 example where you can actually do sort of rather than just casting something to a string, 04:38.160 --> 04:43.840 you can do sort of a GIS operation where you say what is the area of the west village in New York 04:43.840 --> 04:50.320 City and then it goes ahead and gives you the numeric oversold. And so on top of that, there's also 04:50.400 --> 04:56.080 Geo Alchemy, so you can just have sort of a very thin database, like a orm or object relational 04:56.080 --> 05:02.160 marker or just kind of interacting with it. So you can sort of define your tables if you don't really 05:02.160 --> 05:07.840 want to, you know, declare things directly and SQL and you can even go on and make a model 05:07.840 --> 05:13.680 in Geo Jango. I'm not sure if this next slide. But yes, so here's just another example of how 05:13.680 --> 05:18.640 you might see the interface and Python. It's fairly similar, you've got sort of this name space 05:18.720 --> 05:23.120 ST area in the same way that you did in the SQL kind of calling into that. 05:25.760 --> 05:31.440 And so post-cad basically would be taking this idea and applying it in the CAD world. 05:33.360 --> 05:39.280 And so just quick examples, you know, the nice thing is, you know, like copying other people's 05:39.280 --> 05:44.480 work or taking advantage of their work and like in QGIS, there's so much work that's been done in the 05:44.480 --> 05:50.560 post-gressory-all ecosystem, you know, sort of the performance, transactions, locking and so forth. 05:50.560 --> 05:55.040 And there's a whole ecosystem with that as well, so that, you know, we're kind of just 05:55.840 --> 05:59.200 doing sort of like a combinatorial explosion of all of the things that people can do. 06:03.760 --> 06:08.880 And so essentially what I would like to do is, you know, give some people some ideas about how they 06:08.880 --> 06:15.200 might be able to use post-cad. And so just, you know, the very basic is that, you know, 06:15.200 --> 06:20.080 by having a database process somewhere, you can enable a client server model. And so you can 06:21.840 --> 06:26.240 have it so that the heavy load, like an operation that causes heavy load on your laptop, no longer 06:26.240 --> 06:30.880 has it happen locally. And so you can also load it to, let's say, a beefy machine, you know, perhaps 06:30.880 --> 06:39.520 like a company server or, you know, you best top at home. And so you can do sort of data models 06:39.520 --> 06:44.800 on top of the CAD data. So for example, you could have a query like, I would like to show all the 06:44.800 --> 06:51.920 assemblies that have a certain grade of steel. And so with the sort of company local server idea that 06:51.920 --> 06:56.560 I mentioned, just as an example, you could run that sort of query, you could say, you know, perhaps you 06:56.560 --> 07:01.120 do some sort of locking implementation. And perhaps you do some sort of checkout where you, 07:01.120 --> 07:06.000 you know, replicate that data onto a local server or the local process that's also running the same 07:06.000 --> 07:10.400 server, you know, you do some changes. And then you perhaps push it and release the lock. 07:13.280 --> 07:17.200 And also, so essentially, the tricky part, though, I guess we're several tricky parts. 07:17.200 --> 07:21.920 But one of the bad is that, you know, if we are sort of sending off some request, and then we are 07:21.920 --> 07:25.600 going to be waiting for the result of that request, we're going to have some, so we're going to 07:25.600 --> 07:30.320 need some sort of task queue. And so free CAD doesn't exactly have anything like that yet. 07:30.320 --> 07:35.840 But if we sort of create the demand for it, then we could also have, I guess, a better performance 07:35.840 --> 07:46.560 with even without using post-cad. And so post-cad, like I said, is still pre-release. But 07:46.560 --> 07:50.800 if you kind of think in the far future, some of the other things that this might potentially 07:50.880 --> 07:55.440 unlock. So for example, you know, I mentioned OpenCastGate is sort of the elephant in the 07:55.440 --> 08:00.720 room as far as CAD kernels, but there are other options too. So for example, just ERL CAD is 08:00.720 --> 08:06.160 one. There's one that's being written in Rust, a new CAD kernel there. And so essentially, if we 08:06.160 --> 08:13.200 are able to go in and have sort of a thin database wrapper around OpenCastGate, and then perhaps 08:13.200 --> 08:18.320 the higher level database wrapper on top of that, then we can say, you know, Sumerus of this use 08:18.720 --> 08:25.920 higher level API, and then later on, let's say we add BRL CAD support, we can go ahead and say, 08:25.920 --> 08:31.120 oh, perhaps this function or this operation is more performant with BRL CAD and try to make a 08:31.120 --> 08:38.560 good decision to kind of take advantage of more than just OpenCastGate. And so a very interesting 08:38.560 --> 08:43.760 possibility with this too is that, you know, let's say, for example, we have analytics in the 08:43.760 --> 08:48.160 future that tells us, you know, certain patterns, like, let's say you make a pad, and then you've 08:48.160 --> 08:52.960 got to sketch on top of it, perhaps that's going to be a whole. And so before you've actually even 08:53.760 --> 09:00.160 called the function to create the whole, you could speculatively say that this might be coming, 09:00.160 --> 09:04.400 go ahead and offload that to a server, and then go ahead and receive the result, cache it, 09:04.400 --> 09:09.200 and then if the person doesn't do that, they can go ahead and apply that so that they don't have 09:09.200 --> 09:12.960 the sort of overhead of the network latency and everything as soon as they press the button. 09:14.720 --> 09:20.960 And so, potentially also, if they sort of have a sequence of operations that sort of form sort of a 09:20.960 --> 09:26.400 flow graph, then that graph has certain partitions that can be made on top of it, you could separate 09:26.400 --> 09:35.840 those into having multiple different post-cad processes running. So, finished a little bit early, 09:35.840 --> 09:41.280 but I just kind of wanted to open for questions, I guess, as far as feedback and so forth, 09:42.240 --> 09:44.240 if anyone has any questions or something. 09:51.440 --> 09:53.920 Where should we go? 09:57.520 --> 10:00.880 Our architecturally, what does this look like in terms of implementation? 10:00.880 --> 10:06.720 Yeah, so the tricky part is that Postgres is in C, and OpenCascade is in C++, and so essentially 10:06.720 --> 10:13.440 you have to go and do sort of a wrapping of all of the constructors and so forth and 10:13.440 --> 10:19.040 the structures, and it's a bit tedious, and so in OpenCascade they have sort of the bottle example, 10:19.040 --> 10:24.720 if you go into the documentation, and so what I've done so far is I went in there sort of manually 10:24.720 --> 10:31.200 did the bindings for the specific operations that are involved in that, and then sort of just 10:31.200 --> 10:36.400 did sort of the hard coding of the sequel for that. But in the future, I'm going to have to do 10:36.400 --> 10:39.920 some sort of binding generator, but I haven't really gotten to that yet, so. 10:48.640 --> 10:51.840 So, how you're going to deal with the topological maybe problem? 10:52.960 --> 10:55.840 Yeah, so I don't know if that's going to really be, sorry, yeah, 10:55.840 --> 10:59.680 I'm repeating the question, how am I going to deal with the topological name and problem? 10:59.680 --> 11:04.000 I basically, I'm not going to worry about that yet. I think that in terms of 11:04.960 --> 11:10.400 the interface, the first step is to sort of span the OpenCascade library in terms of the 11:10.400 --> 11:16.480 CAD data types and operations, and then we can sort of say implement heristics and so forth 11:16.480 --> 11:20.400 afterwards, but essentially the first step I think is just to have everything available. 11:34.640 --> 11:48.160 Hi, thanks. Can you give some examples of the GIS ecosystem that would translate to the 11:48.160 --> 11:54.000 CAD world? So, just to give us a bit more. Sure, yeah, so the question was about the relationship 11:54.000 --> 11:59.600 between the GIS ecosystem and the CAD world. So GIS, just as an example, if you imagine you have 11:59.680 --> 12:04.960 a point on the earth, so you then would want to find, let's say, maybe two points, and you want to find 12:04.960 --> 12:09.680 the distance on the sphere, you're dealing with geometry or connecting this, so let's say, 12:09.680 --> 12:17.280 different tracks of land, and so in terms of like geometry, topology, and so forth, you have sort of 12:17.280 --> 12:21.280 underlying a lot of the underlying mathematics is the same, but you just have different applications. 12:29.680 --> 12:40.240 So, maybe going back to the early motivation. So, how is it done today with OpenCascade? 12:40.240 --> 12:51.920 Does there have database or what? Yes. So, I see the move from GIS to CAD or your content 12:51.920 --> 12:57.680 is, but yes, I'm bit surprised to see the database in the middle of OpenCascade. 12:57.680 --> 13:04.160 Well, so the question was about sort of the current approach as far as a database with OpenCascade, 13:04.160 --> 13:10.000 and so OpenCascade, it doesn't really have any conception of that, I guess I would say. 13:10.000 --> 13:14.800 So, they have, I can mention the data types, operations, file formats, and exchanges, 13:14.800 --> 13:20.560 visualization, and so forth, but in terms of the actual data, it's basically limited to the file system. 13:22.880 --> 13:28.720 If you don't, in fact, use the database of all the existing metadata of the database. 13:29.440 --> 13:34.720 It might not go down the process, I mean, if you want to say, okay, I want to use this space, 13:34.720 --> 13:37.920 all these graphics, and you want to go to the database. 13:37.920 --> 13:41.440 Yeah, so the question was sort of about the performance impacts of the database. 13:41.440 --> 13:47.520 Yes, so absolutely, you know, sort of the recreation of objects, the network latency, and so forth, 13:47.520 --> 13:53.680 it will not necessarily be more performant for small data, but I think for larger data, 13:53.680 --> 13:59.440 or in the case that I mentioned, the speculative execution, if we can mask that sort of overhead, 13:59.440 --> 14:04.960 then the, especially one other thing, too, is that let's say, for example, we have, you know, 14:04.960 --> 14:10.640 configuration option as the database details, and we have, you know, a sort of a button, a smart 14:10.640 --> 14:14.640 button, which says, you know, if you are configured to connect to a database, you know, 14:14.640 --> 14:19.200 perhaps this button will, you know, use that database, but instead, it could actually, 14:19.200 --> 14:22.960 if you don't have that configured, you would just use the sort of the normal current approach 14:22.960 --> 14:28.560 of running things locally. And so, you know, kind of depends, and so one of the, I guess, 14:28.560 --> 14:32.560 applications that I'm thinking of with this is like a Raspberry Pi, and so with that, you know, 14:32.560 --> 14:36.320 if someone's running, like an educational context, you have a classroom with a whole bunch of 14:36.320 --> 14:40.720 people that are limited by their SD cards, and so, especially with the machine, even with the 14:41.280 --> 14:47.200 Pi 5 being fairly decent for running freecat currently, the SD card is a huge limitation. 14:47.200 --> 14:53.680 And so, in that case, the trade-off of that versus the network, and so forth, could be acceptable. 14:53.680 --> 14:58.720 And so, it's kind of about introducing choice and the potential for people to use it in ways 14:58.720 --> 14:59.680 that you might not imagine. 15:00.400 --> 15:15.760 Sorry, I'm still trying to write my head around this, but so, I think you use open cascades, mostly, 15:15.760 --> 15:26.080 to generate geometry. So, but so, you can do a query to postcat, and then it generates the 15:26.080 --> 15:30.160 geometry and user with three steps from the database, and then that is cached, or... 15:30.160 --> 15:35.520 Well, so, yeah, the question was about, you know, that the typical use of open cascades would 15:35.520 --> 15:39.920 be to generate some geometry, but if you think, for example, that the case of finding an 15:39.920 --> 15:45.120 intersection of complicated parts, that's the sort of thing where having the work be offloaded 15:45.120 --> 15:50.240 might make more sense. But if you're just, you know, doing sort of a human scale, or even like 15:50.240 --> 15:57.440 hobby of scale had the data, it may not make sense there. So, so, you assume also a database of 15:57.440 --> 16:03.600 existing geometry. Well, so, in that case, the data would already be on that database server, 16:03.600 --> 16:09.520 and so, you don't have any data except for the view inside of freecat, the data is in the 16:09.520 --> 16:13.840 server, and so, it's not like you're sending something there, and then the operation is happening, 16:13.840 --> 16:21.440 it's already being done inside of that server. But yes, you could also have a database of 16:21.440 --> 16:26.400 existing geometry, like a part library, you know, in the case of like the company, you know, 16:26.400 --> 16:32.240 assemblies of steel with a certain grade, and also one thing too, with that is that, you know, 16:32.240 --> 16:36.240 postgres, there's all this like access control, and so forth, and so you could have different levels 16:36.240 --> 16:39.440 of permissions, and so forth, for different parts, which, you know, you could also implement, 16:39.440 --> 16:43.520 like let's say, like the API level or the application level for like a web app, 16:43.520 --> 16:55.040 but you could also have it inside of the database. So, how are you distinguishing properties 16:55.040 --> 17:02.960 that are intrinsic in the open cascade of models versus properties that you would be assigning 17:03.040 --> 17:10.400 in the databases, they're a way that you're thinking of programmatically keeping those distinct 17:10.400 --> 17:15.760 in your implementation? Yeah, so, I would say talking about distinguishing the sort of database 17:15.760 --> 17:23.760 properties and open cascade properties, let me go back to a slide here. So, essentially with that, 17:23.760 --> 17:28.080 I would probably just be doing some sort of pre-fixing for, to create a sort of a namespace, 17:28.080 --> 17:32.080 and so I would have sort of one that specifically for open cascade, maybe, and then maybe one 17:32.080 --> 17:36.640 for post-cad itself, and then just have the post-cad assume that open cascade is what's being used, 17:36.640 --> 17:41.040 so that people sort of get started using the higher level interface so that I can change the 17:41.040 --> 17:53.440 implementation details afterwards. Ask question? Okay, thank you, Kurt. Thanks.