Basically it uses actix for the backend and yew (Vue-like rust frontend framework) for the frontend. This enables one to share types (and helper functions) between both, which is great:
Hey, I'm the lead engineer at Picterra. Would be happy to answer any questions.
What we are trying to do is indeed allow customers to build algorithms tailored to their use cases. We often joke that the reason our ML works is because we are overfitting to customer datasets/use cases. But I think that's somewhat true in the sense that we are not going for "worldwide trees counting" but more for "reliably count cars on these 50 parcels".
It's also interesting to note that a sizeable chunk of our revenue is coming from companies with drone data where it makes even more sense to be specific to customer data (resolution, time of day, geo, etc...).
Picterra | ML / Fullstack / Backend Engineers | Full-Time | REMOTE (EU only) or ONSITE (Lausanne, CH)
We are building a geospatial machine learning platform that allows users to detect any kind of object and train their own Deep Learning model in the cloud using an intuitive UI. That means we get to tackle interesting problems on a daily basis; from processing and visualizing large amounts of geospatial data to dynamically managing GPU workers, while exposing this to our users in a collaborative and intuitive web interface.
Our tech stack is Python/Django/Postgres on the backend and Vue on the front-end. We’re using PyTorch for our Deep Learning algorithms and deploy on Google Kubernetes Engine. We are working with geospatial data, so we are heavy users of GDAL, Mapbox, Leaflet, QGIS, and other GIS tools.
I would guess they have a system such that after a user has passed N captchas successfully, they trust its a human and start displaying them (a portion of) unlabelled captchas that will always succeed and that's when novel labelling happens.
Or something along those lines. And then you can get creative displaying same captcha to multiple users, etc...
We are a top tier VC-backed up start-up based in Lausanne, Switzerland. We are building the Google
Search for the physical world. Our ambition is to give everyone–not just data scientists and
developers–the opportunity to analyze and draw real-time insights from satellite and aerial imagery, all in just a few clicks.
We are looking for a Software Engineer with experience (~5 years) and interest in Backend/DevOps. You will join our small (currently 5) development team to help us scale our machine learning platform. Our scale challenges are mostly around data and efficient GPU utilization and not so much about number of concurrent users.
We have a Vue.js/Python/Django/DRF/Postgres/Docker/Kubernetes stack.
Picterra | Full stack Engineer | Lausanne or Berlin | Onsite | Full-Time | https://picterra.ch/
Looking for a Full-stack Software Engineer to join the Picterra team ! We build a web platform which allow our users to train custom object detectors for satellite/drone/aerial imagery. Our core idea is to use machine learning to make earth observation easier & more accessible.
We are still a small company (6), so now is the good time to join if you want to have an impact and be involved in product and engineering decisions.
We are working on quite cool stuff, with a highly interactive geospatial frontend (vue + leaflet + webgl). Our backend (python + django) ingests geospatial data and runs machine learning jobs on it and we deploy all of this to AWS with some scaling challenges ahead of us.
Apply through our website : https://picterra.ch/about/ or send me a mail at julien.rebetez [at] picterra.ch
I work at Picterra[1], a swiss company doing machine learning on drone & satellite imagery.
From discussion with a number of drone service providers, it seems to me the restrictiveness really depends on the context.
For things involving flying a drone over a crowded area, it's definitely hard to get authorization and we've seen projects being abandoned because of that. So yeah, drone delivery in cities might take some time before it is allowed.
On the other hand, most of the commercial applications I've seen are around using drones for mapping. So basically taking pictures and then processing them (create orthophotos, build a 3D model, detect objects, etc...). This usually doesn't involve flying over crowd and for a number of use cases (farms, construction site, security) the fly would be over a private property. A lot of people are able to do this without any legal restrictions.
From what I know of the history of the swiss Drone Valley, the two biggest success are sensefly [2] and Pix4D [3] and those are in the mapping business.
Two of the booming startups would be wingtra [4] and flyability [5]. Wingtra seems to be mapping-oriented as well and Flyability develop drones that can fly inside. So a lot of the swiss drone valley is really into drones that can take pictures for mapping & inspection and I think this segment will continue to see massive growth in the future.
> On the other hand, most of the commercial applications I've seen are around using drones for mapping. So basically taking pictures and then processing them (create orthophotos, build a 3D model, detect objects, etc...).
In my opinion, the majority of those applications are better served by either CCTV or manned aircraft.
Mapping use cases - If the area is big enough, manned aircraft mapping is much cheaper than drone mapping. Typical airplane ortho is around the 10cm/pixel, so it is sufficient for the majority of use cases. E.g. Check our nearmap. If the area is small, the machine learning is not going to make lots of $, as it's better to just use humans.
Monitoring use cases - e.g. "I want to detect if construction workers are wearing helmets" or "I want to detect poachers in the area". You can provide more business value by doing computer vision on CCTV camera.
I'm not sure exactly what Netflix means by "if the job breaks", but I've used jupyter notebook in production to do ML before.
If you consider the notebook as a way to augment your logs with plots, it might make a bit more sense.
Running a jupyter notebook is a nice way to generate a HTML report for a job. For a typical ML pipeline, you first plot some stats about the input data, then train some model, plot some training loss, a confusion matrix, some example of predictions, etc...
If some job gives a strange result (maybe that's what they mean by break), having the notebook rendered as an HTML page with all the plot is a very effective way to do a first round of diagnostics. You can also start the notebook with the same parameters and 'run' through your report, which is a nice way to do interactive debugging.
Also in this case, the notebook itself was quite small in terms of lines of code. All the functions were implemented in modules, so it's really like the notebook is your 20 lines 'main' function. So you need some discipline among your team.
Regarding the error, they are logged when a verify_block/transaction returns False, just to be a bit more explicit about what failed. In a real implementation, I guess you would throw exceptions instead (or use some Result pattern), but I tried and it cluttered the code quite a bit, so I went back to logging.
https://github.com/julienr/liveboard-rs
Basically it uses actix for the backend and yew (Vue-like rust frontend framework) for the frontend. This enables one to share types (and helper functions) between both, which is great:
https://github.com/julienr/liveboard-rs/blob/master/shared/s...
That being said, I think maturity-wise, Typescript is probably a better bet for this right now, so I'll definitely look at trpc for $dayjob.