Monday, June 14, 2021

Connected Components 1 - The naïve approach

Getting started on connected-components segmentation, starting from assuming very little in the way of prior knowledge:


Read more...

Monday, May 24, 2021

Fast Discrete Radon Transformation

I didn't think this one would take as long as it did to produce, but I didn't think the explanation would demand as long a video as it did. 

Finding straight lines with the Fast Discrete Radon Transformation.


Read more...

Monday, May 10, 2021

The card reader and the Hough transform

We use the Hough Transform to find the straight lines in the image and finish getting the bits from the punched card.
Read more...

Monday, May 3, 2021

Image preparation for the card reader

Ths stuff in this video is the “bread and butter&drquo; of image processing. Experienced computer visionaries will have heard it all before.
Read more...

Monday, April 19, 2021

Image analysis and the Organ, part 1: Intro to k-means segmentation

New thread: using a document scanner to read an old stack of IBM cards. (Re-do of a ten-year-old project, but with videos discussing the algorithms.)

This week: introduction to k-means segmentation.


Read more...

Tuesday, November 17, 2020

2020-11-16 Shield tables bug found, at last

I finally found the source of the duplicated data in the OSM shield tables. It turns out that since the 'shieldway' table is a per-way table, it's cleaned out only if a way is deleted or replaced, and not if the way is just updated.

I wrote it up in detail in an issue at the osm2pgsql project. so I'm not going to repeat a lot of text here. With various work-arounds, I'm to the point where I can handle:

  • inserts, updates, and deletes of ways
  • inserts and updates of route relations

Deleting route relations causes a mess. Everything is deleted cleanly by referential integrity constraints ON DELETE CASCADE, but then the Lua script goes and reinserts the relation memberships back into the shieldway table, violating its foreign key constraint since the relation is no longer there.

I can't see a workaround for that bit, so I opened the issue above as a cry for help.

Fortunately, it's vanishingly rare to delete a route relation, so I think I can run for a while this way, and move on to trying for minutely updates. I think the next step is just that - work out how to switch osmosis to pulling from the main OSM database and trigger it minutely. I see there's a Wiki page on the subject, and I have the polygon files for the extracts I'm working with. How hard can it be? (Yes, I know, that phrase is right up there with “hold my beer,” but I'm a crazy programmer.

Next up after that, I think, will be to see if I can switch my personal map server over to auto-generated and cached tiles. That'll probably involve retooling the server to run off Apache or Nginx rather than althttpd, which fills me with dread, because I love the “zero administration” aspects of the latter - Richard Hipp is a master of the “It Just Works” school of software design. But I really want to see if going to tiles generated on the fly would allow it to scale to a whole continent, rather than about a fourth of the Lower 48 of the US.


Read more...

Monday, November 16, 2020

2020-11-15 Trying to update shield tables

Now that I have managed to speed up the part of updating the shield tables so that it could possibly run once a minute, I'm trying to run tests first with daily updates from geofabrik.de. I'm not having all that much success yet.

The update is running without complaint, but I'm finding that if a route relation is modified in the update, I get two or three copies of the member ways in the database. That surely won't work!

It's not obvious to me what's going on. There are no errors from the Lua script that's loading the database, It's just generating redundant entries. The initial load doesn't do that, and it's the same code.

I've also removed the primary key from the 'shieldways' table for now, because with that left in place, the duplicate rows did indeed cause a crash.

Gotta look into this more tomorrow.


Read more...