So hello everyone, the sound okay here. Yeah, so I have a sort of a three-release project
that I sort of want to drum up some interest for, get some early feedback on, and it's
called postcat. I've got a terrible sort of self-drawn logo there, but I just wanted to
get something started with that. So quick bio about me, yeah, freecat, I would say this
is my main work as dependencies distribution and infrastructure. I'm also a member of the
FPA, I'm a devine developer, and then sort of my educational background there, biological
and agricultural engineering, and then I'm about to finish up my masters and see yes.
And so this talk is a little tricky to calibrate, because I don't think there are very
many people who are in the center of this and in diagram, really the only kind of need to
note the CAD and databases aspect, but I am using a motivating example from the world of geospatial
software, specifically QGIS, and so if anyone kind of already has any familiarity with
that that helps, but I will try to make it not so necessary, it's much far. And so for
anyone who's not super familiar with OpenCastCade, so it's what's used by freecat for sort
of its CAD, geometry, operations, and data, and so forth. But it's got several problems,
it's sort of a behemoth, it's got sort of its own C++, say, they're on smart pointers and
so forth before that became a standard, and so there's just difficulty in contributing
to it. But essentially, if we get more people using it, it'll benefit us all, because
as soon as a developer starts using it, that's the first step on the path to potentially
becoming a contributor. And even if they can't, let's say, for example, fix the sort
of the holy grail problem of like the fillet operation, for example, which is very, very
buggy, even if they can't do that, they can potentially free up another person by contributing.
And so essentially, if we can sort of plant a seed and then grow an ecosystem, it should
help us all. And so there's several ways people are using OpenCastCade already, besides
freecat, and of course, keycat as well. And so you can think of it in terms of, at the language
level, so people are using Python bindings, or JavaScript bindings, and so forth. But in this
case, I'm actually proposing sort of an architectural, a switch in sort of the architecture
and how you can interact with it by putting OpenCastCade in the database. And so this is one
of my favorite things about open source and free software, is just that we can essentially
pull this one and go and look at what people in QGIS are doing and say, this looks pretty cool,
let's just copy everything. And so I'm going to essentially run through what they're doing with it
and kind of explain postGIS, which is the inspiration for postcat.
And so just to begin with, if anyone has used QGIS before on the left side of the screen, sort of
where freecat has its model tree, they instead have sort of this browser here. And so you can see
you've got, you know, your file system and so forth, but then you also have postGIS specifically
and then potentially other databases. Since once the postGIS came around, even like let's say
spatialite, they decided, okay, let's kind of take this idea and spread it throughout the whole
database world. And so we can have, you know, file based databases for GIS and so forth, not just
a heavy server process. And so QGIS is sort of how I first learned about postGIS, but there's a
whole ecosystem around it, specifically we've got like the leaflet GIS for making web apps. You've
got geojango if you just want to make, like, let's say an API and even like a flask if you just want
to have something very small and simple and there's lots of other sort of integrations, there's
a whole ecosystem there. And so just to kind of give you a specific example, this text small,
but this kind of shows you exactly how one might use postGIS. And so in the first section here,
we have a query, we are doing sort of a little bit of normal SQL where we do like select name,
but then we have this sort of special function here, STS text and then we have the geometry.
And so the output there is essentially this string representation of the postGIS data type
showing you the latitude and the longitude there. And so you can also, yeah, so here's another
example where you can actually do sort of rather than just casting something to a string,
you can do sort of a GIS operation where you say what is the area of the west village in New York
City and then it goes ahead and gives you the numeric oversold. And so on top of that, there's also
Geo Alchemy, so you can just have sort of a very thin database, like a orm or object relational
marker or just kind of interacting with it. So you can sort of define your tables if you don't really
want to, you know, declare things directly and SQL and you can even go on and make a model
in Geo Jango. I'm not sure if this next slide. But yes, so here's just another example of how
you might see the interface and Python. It's fairly similar, you've got sort of this name space
ST area in the same way that you did in the SQL kind of calling into that.
And so post-cad basically would be taking this idea and applying it in the CAD world.
And so just quick examples, you know, the nice thing is, you know, like copying other people's
work or taking advantage of their work and like in QGIS, there's so much work that's been done in the
post-gressory-all ecosystem, you know, sort of the performance, transactions, locking and so forth.
And there's a whole ecosystem with that as well, so that, you know, we're kind of just
doing sort of like a combinatorial explosion of all of the things that people can do.
And so essentially what I would like to do is, you know, give some people some ideas about how they
might be able to use post-cad. And so just, you know, the very basic is that, you know,
by having a database process somewhere, you can enable a client server model. And so you can
have it so that the heavy load, like an operation that causes heavy load on your laptop, no longer
has it happen locally. And so you can also load it to, let's say, a beefy machine, you know, perhaps
like a company server or, you know, you best top at home. And so you can do sort of data models
on top of the CAD data. So for example, you could have a query like, I would like to show all the
assemblies that have a certain grade of steel. And so with the sort of company local server idea that
I mentioned, just as an example, you could run that sort of query, you could say, you know, perhaps you
do some sort of locking implementation. And perhaps you do some sort of checkout where you,
you know, replicate that data onto a local server or the local process that's also running the same
server, you know, you do some changes. And then you perhaps push it and release the lock.
And also, so essentially, the tricky part, though, I guess we're several tricky parts.
But one of the bad is that, you know, if we are sort of sending off some request, and then we are
going to be waiting for the result of that request, we're going to have some, so we're going to
need some sort of task queue. And so free CAD doesn't exactly have anything like that yet.
But if we sort of create the demand for it, then we could also have, I guess, a better performance
with even without using post-cad. And so post-cad, like I said, is still pre-release. But
if you kind of think in the far future, some of the other things that this might potentially
unlock. So for example, you know, I mentioned OpenCastGate is sort of the elephant in the
room as far as CAD kernels, but there are other options too. So for example, just ERL CAD is
one. There's one that's being written in Rust, a new CAD kernel there. And so essentially, if we
are able to go in and have sort of a thin database wrapper around OpenCastGate, and then perhaps
the higher level database wrapper on top of that, then we can say, you know, Sumerus of this use
higher level API, and then later on, let's say we add BRL CAD support, we can go ahead and say,
oh, perhaps this function or this operation is more performant with BRL CAD and try to make a
good decision to kind of take advantage of more than just OpenCastGate. And so a very interesting
possibility with this too is that, you know, let's say, for example, we have analytics in the
future that tells us, you know, certain patterns, like, let's say you make a pad, and then you've
got to sketch on top of it, perhaps that's going to be a whole. And so before you've actually even
called the function to create the whole, you could speculatively say that this might be coming,
go ahead and offload that to a server, and then go ahead and receive the result, cache it,
and then if the person doesn't do that, they can go ahead and apply that so that they don't have
the sort of overhead of the network latency and everything as soon as they press the button.
And so, potentially also, if they sort of have a sequence of operations that sort of form sort of a
flow graph, then that graph has certain partitions that can be made on top of it, you could separate
those into having multiple different post-cad processes running. So, finished a little bit early,
but I just kind of wanted to open for questions, I guess, as far as feedback and so forth,
if anyone has any questions or something.
Where should we go?
Our architecturally, what does this look like in terms of implementation?
Yeah, so the tricky part is that Postgres is in C, and OpenCascade is in C++, and so essentially
you have to go and do sort of a wrapping of all of the constructors and so forth and
the structures, and it's a bit tedious, and so in OpenCascade they have sort of the bottle example,
if you go into the documentation, and so what I've done so far is I went in there sort of manually
did the bindings for the specific operations that are involved in that, and then sort of just
did sort of the hard coding of the sequel for that. But in the future, I'm going to have to do
some sort of binding generator, but I haven't really gotten to that yet, so.
So, how you're going to deal with the topological maybe problem?
Yeah, so I don't know if that's going to really be, sorry, yeah,
I'm repeating the question, how am I going to deal with the topological name and problem?
I basically, I'm not going to worry about that yet. I think that in terms of
the interface, the first step is to sort of span the OpenCascade library in terms of the
CAD data types and operations, and then we can sort of say implement heristics and so forth
afterwards, but essentially the first step I think is just to have everything available.
Hi, thanks. Can you give some examples of the GIS ecosystem that would translate to the
CAD world? So, just to give us a bit more. Sure, yeah, so the question was about the relationship
between the GIS ecosystem and the CAD world. So GIS, just as an example, if you imagine you have
a point on the earth, so you then would want to find, let's say, maybe two points, and you want to find
the distance on the sphere, you're dealing with geometry or connecting this, so let's say,
different tracks of land, and so in terms of like geometry, topology, and so forth, you have sort of
underlying a lot of the underlying mathematics is the same, but you just have different applications.
So, maybe going back to the early motivation. So, how is it done today with OpenCascade?
Does there have database or what? Yes. So, I see the move from GIS to CAD or your content
is, but yes, I'm bit surprised to see the database in the middle of OpenCascade.
Well, so the question was about sort of the current approach as far as a database with OpenCascade,
and so OpenCascade, it doesn't really have any conception of that, I guess I would say.
So, they have, I can mention the data types, operations, file formats, and exchanges,
visualization, and so forth, but in terms of the actual data, it's basically limited to the file system.
If you don't, in fact, use the database of all the existing metadata of the database.
It might not go down the process, I mean, if you want to say, okay, I want to use this space,
all these graphics, and you want to go to the database.
Yeah, so the question was sort of about the performance impacts of the database.
Yes, so absolutely, you know, sort of the recreation of objects, the network latency, and so forth,
it will not necessarily be more performant for small data, but I think for larger data,
or in the case that I mentioned, the speculative execution, if we can mask that sort of overhead,
then the, especially one other thing, too, is that let's say, for example, we have, you know,
configuration option as the database details, and we have, you know, a sort of a button, a smart
button, which says, you know, if you are configured to connect to a database, you know,
perhaps this button will, you know, use that database, but instead, it could actually,
if you don't have that configured, you would just use the sort of the normal current approach
of running things locally. And so, you know, kind of depends, and so one of the, I guess,
applications that I'm thinking of with this is like a Raspberry Pi, and so with that, you know,
if someone's running, like an educational context, you have a classroom with a whole bunch of
people that are limited by their SD cards, and so, especially with the machine, even with the
Pi 5 being fairly decent for running freecat currently, the SD card is a huge limitation.
And so, in that case, the trade-off of that versus the network, and so forth, could be acceptable.
And so, it's kind of about introducing choice and the potential for people to use it in ways
that you might not imagine.
Sorry, I'm still trying to write my head around this, but so, I think you use open cascades, mostly,
to generate geometry. So, but so, you can do a query to postcat, and then it generates the
geometry and user with three steps from the database, and then that is cached, or...
Well, so, yeah, the question was about, you know, that the typical use of open cascades would
be to generate some geometry, but if you think, for example, that the case of finding an
intersection of complicated parts, that's the sort of thing where having the work be offloaded
might make more sense. But if you're just, you know, doing sort of a human scale, or even like
hobby of scale had the data, it may not make sense there. So, so, you assume also a database of
existing geometry. Well, so, in that case, the data would already be on that database server,
and so, you don't have any data except for the view inside of freecat, the data is in the
server, and so, it's not like you're sending something there, and then the operation is happening,
it's already being done inside of that server. But yes, you could also have a database of
existing geometry, like a part library, you know, in the case of like the company, you know,
assemblies of steel with a certain grade, and also one thing too, with that is that, you know,
postgres, there's all this like access control, and so forth, and so you could have different levels
of permissions, and so forth, for different parts, which, you know, you could also implement,
like let's say, like the API level or the application level for like a web app,
but you could also have it inside of the database. So, how are you distinguishing properties
that are intrinsic in the open cascade of models versus properties that you would be assigning
in the databases, they're a way that you're thinking of programmatically keeping those distinct
in your implementation? Yeah, so, I would say talking about distinguishing the sort of database
properties and open cascade properties, let me go back to a slide here. So, essentially with that,
I would probably just be doing some sort of pre-fixing for, to create a sort of a namespace,
and so I would have sort of one that specifically for open cascade, maybe, and then maybe one
for post-cad itself, and then just have the post-cad assume that open cascade is what's being used,
so that people sort of get started using the higher level interface so that I can change the
implementation details afterwards. Ask question? Okay, thank you, Kurt. Thanks.