I want to rasterize a shapefile in C or C++ using GDAL.
But the GDAL documentation is not explicit enough for me.
Does someone have a code sample, useful links or advice on how to do it properly?
Thanks.
This is the code I'm try to use but get error GDALRasterize(filename1,NULL,lineDS_shp, NULL,NULL)
GDALAllRegister();
char filename1[]="./datas/myRaster.tiff";
char filename3[]="./datas/janze_montlouis_transparent_mosaic_group1.tif";
char filename2[]="./datas/ExportPolylignes_lines.shp";
GDALDatasetH lineDS,lineDS_shp;
lineDS_shp = GDALOpenEx(filename2, GDAL_OF_VECTOR, NULL, NULL, NULL
);
lineDS = GDALRasterize(filename1,NULL,lineDS_shp,NULL,NULL);
GDALClose(lineDS_shp);
GDALClose(lineDS);
ERROR 1: Size and resolutions are missing
Process finished with exit code 0
Related
I am attempting to make a PDF417 barcode reader for the web using Web Assembly (there's a few out there but the only reliable one is licenced). The idea is simple, just build a binary file with C code that can be called via JavaScript.
I followed this guide which got me almost there! I had to add --enable-codes=pdf417 as a parameter to configure to enable PDF417 symbols and disable all the others I'm not interested in.
The code actually works amazingly well for any other type of symbol (see demo) but if I compile ZBar to accept PDF417, it detects it but throws a warning:
WARNING: zbar/decoder/pdf417.c:73: pdf417_decode8: Assertion "clst >= 0 && clst < 9" failed.
dir=0 sig=5a44 k=9 buf[0000]=
WARNING: zbar/decoder/pdf417.c:89: pdf417_decode8: Assertion "g[0] >= 0 && g[1] >= 0 && g[2] >= 0" failed.
dir=1 sig=ca03 k=6 g0=ffffffff g1=e71 g2=585 buf[0000]=
Those assertions are on lines 71 and 86 of ZBar.
You can see all the code I'm using in the guide I mentioned earlier (the only difference is that I enabled PDF417 before compiling) ¿Any ideas?
The default behaviour of zbar is to attempt to decode all symbol types.
if(sym == ZBAR_NONE) {
static const zbar_symbol_type_t all[] = {
ZBAR_EAN13, ZBAR_EAN2, ZBAR_EAN5, ZBAR_EAN8,
ZBAR_UPCA, ZBAR_UPCE, ZBAR_ISBN10, ZBAR_ISBN13,
ZBAR_I25, ZBAR_DATABAR, ZBAR_DATABAR_EXP, ZBAR_CODABAR,
ZBAR_CODE39, ZBAR_CODE93, ZBAR_CODE128, ZBAR_QRCODE,
ZBAR_PDF417, 0
};
const zbar_symbol_type_t *symp;
for(symp = all; *symp; symp++)
zbar_decoder_set_config(dcode, *symp, cfg, val);
return(0);
}
Does your images contain PDF417 barcodes? If not, you could instruct zbar to decode just the symbol types of that are of interest to you, so the PF417 decoder will not be run. You do this using the symbols argument e.g., if your images contain just QR codes,
// disable all
scanner.set_config(ZBAR_NONE, ZBAR_CFG_ENABLE, 0);
// enable qr
scanner.set_config(ZBAR_QRCODE, ZBAR_CFG_ENABLE, 1);
in pyzbar
from pyzbar.pyzbar import ZBarSymbol
decode(Image.open('pyzbar/tests/qrcode.png'), symbols=[ZBarSymbol.QRCODE])
For anyone trying to use ZBar for reading PDF417, PDF417 decoding is incomplete. It will not work. Your best open source bet is ZXing.
I'm trying to record sound using Audio Queue, but every time I want to write to file I get the message AudioFileCreateWithURL failed('wht?'). I haven't been able to find a corresponding solution to this error, for I haven't found a similar (wht?) error elsewhere. I acquired the code from Apple's official guide for Audio Queue programming and it looks like this:
char* filePath = "Users/linus/voicies/output.wav";
CFURLRef myFileURL = CFURLCreateFromFileSystemRepresentation( // 1
NULL, // 2
(const UInt8 *) filePath, // 3
strlen (filePath), // 4
false // 5
);
OSStatus err = AudioFileCreateWithURL(
myFileURL,
kAudioFileWAVEType,
&recordFormat,
kAudioFileFlags_EraseFile,
&recorder.recordFile
);
CheckError(err);
in which CheckError finds the corresponding error, which is (wht?). I have no idea what that means and what I must do to make it happen, since the code I have used is almost identical to the sample codes. I appreciate any kind of clue.
Good afternoon, I'm facing a problem on my c code and I don't know what is causing it.
Every time I try to print characters like these: "┌──┐" my program simply prints some strange characters, like on this screenshot:
I'm using Qt Creator on Windows, with Qt version 5.5.0 MSVC 64 bits. The compiler is the Microsoft Visual C++ Compiler 12.0 (amd64).
I tried changing the locale but with no success. The only way I found to print these characters was to define them as int variables with the ASCII code and printing them, but it led to some really extensive and ugly coding, like this:
int cSupEsq = 218; //'┌'
int cSupDir = 191; //'┐'
int cInfEsq = 192; //'└'
int cInfDir = 217; //'┘'
int mVert = 179; //'│'
int mHor = 196; //'─'
int espaco = 255; //' '
int letraO = 111; //'o'
//Inicia limpando a tela da aplicação
clrscr();
//Linha 1
printf("%c", cSupEsq);
for (i = 1; i < 79; i++) { printf("%c", mHor); }
printf("%c", cSupDir);
Is there any way I can make the program treat these characters correctly? What could be causing this problem?
Your solution to use the OEM code points is the right way to go, codepage 850/437 is the default code page for the console and therefore should work. You could also use SetConsoleOutputCP to ensure the correct code page is used for the console.
Having said that, what is happening when you do not use your workaround is that the source file is being saved using a different codepage ie. not codepage 850/437. The in memory representation of the source code is Unicode (probably UTF-8), when you save the file the in memory representation of the characters are mapped to the target code page for the file.
What you can do is to save the file using the 850/437 codepage as the target, I don't know how you do this in Qt Creator (If you can at all), in Visual Studio for example you can select the down arrow on the Save button and select "Save with encoding", you can then proceed to select the target codepage, in your case code page 850. This will ensure that the in memory code points are mapped correctly to the file to be compiled.
I hope that helps explain the issue.
It shouldn't be necessary to print the characters one at a time. Instead, you can use an escape sequence:
printf("\xDA\xBF\xC0\xD9\xB3\xC4\xFF");
Can anybody help me to find out how to call rrd_update_r function of the rrdtool c API from http://oss.oetiker.ch/rrdtool/index.en.html?
It was quite easy to call the non-threadsafe version of rrd_update, but this one is more tricky...
normal rrd_update:
char *updateparams[] = {
"rrdupdate",
rrd_file,
values,
NULL
};
rrd_clear_error();
result = rrd_update(3, updateparams); //argc is first arg
Because the programm has to run in a multithreaded environment I got several errors by not using the threadsafe functions!
But it is not so easy to use rrd_update_r, because it requires a template too...
int rrd_update_r(const char *filename, const char *_template,
int argc, const char **argv);
and I really have no idea how to create one...
char *updateparams[] = {
"rrdupdate",
rrd_file,
values,
NULL
};
rrd_clear_error();
result = rrd_update_r(rrd_file, NULL,3, updateparams);
does not work and produces the following error when executing it...
error: /var/tmp/rrds/1.rrd: expected timestamp not found in data source from rrdupdate
Hopefully someone can help me!
thx and br,
roegi
Well, looking at the source code...
It appears that rrd_update_r does not want to see the "rrupdate" argument. So try just passing rrd_file and values as a 2-element argv.
Actually the source for rrd_update is not hard to read; you can find it in src/rrd_update.c. And rrd_update_r appears to be a much lower-level function that rrd_update itself calls. So this may not actually fix your underlying problem.
Now it is working!
Nemo - thx for your help!
It was not exactly your solution but it was a hint to the right direction!
It works with:
/*
rrd_file is a char * to "/var/tmp/1.rrd"
NULL says not to use a template
1 --> argc
values is a char * to "N:value-1:value-2:.....:value-n"
*/
result = rrd_update_r(rrd_file, NULL, 1, (void *) &values);
I am trying to wrap a C library into Perl. I have tinkered with XS but being unsuccessful I thought I should start simply with Inline::C. My question is on Mortalization. I have been reading perlguts as best as I am able, but am still confused. Do I need to call sv_2mortal on an SV* that is to be returned if I am not pushing it onto the stack?
(PS I really am working on a less than functional knowledge of C which is hurting me. I have a friend who knows C helping me, but he doesn't know any Perl).
I am providing a sample below. The function FLIGetLibVersion simply puts len characters of the library version onto char* ver. My question is will the version_return form of my C code leak memory?
N.B. any other comments on this code is welcomed.
#!/usr/bin/perl
use strict;
use warnings;
use 5.10.1;
use Inline (
C => 'DATA',
LIBS => '-lm -lfli',
FORCE_BUILD => 1,
);
say version_stack();
say version_return();
__DATA__
__C__
#include <stdio.h>
#include "libfli.h"
void version_stack() {
Inline_Stack_Vars;
Inline_Stack_Reset;
size_t len = 50;
char ver[len];
FLIGetLibVersion(ver, len);
Inline_Stack_Push(sv_2mortal(newSVpv(ver,strlen(ver))));
Inline_Stack_Done;
}
SV* version_return() {
size_t len = 50;
char ver[len];
FLIGetLibVersion(ver, len);
SV* ret = newSVpv(ver, strlen(ver));
return ret;
}
Edit:
In an attempt to answer this myself, I tried changing the line to
SV* ret = sv_2mortal(newSVpv(ver, strlen(ver)));
and now when I run the script I get the same output that I did previously plus an extra warning. Here is the output:
Software Development Library for Linux 1.99
Software Development Library for Linux 1.99
Attempt to free unreferenced scalar: SV 0x2308aa8, Perl interpreter: 0x22cb010.
I imagine that this means that I don't need to mortalize in this case? I suspect that the error is saying that I marked for collection something that was already in line for collection. Can someone confirm for me that that is what that warning means?
I've been maintaining Set::Object for many years and had this question, too - perhaps best to look at the source of that code to see when stuff should be mortalised (github.com/samv/Set-Object). I know Set::Object has it right after many changes. I think though, it's whenever you're pushing the SV onto the return stack. Not sure how Inline changes all that.