Uso de geotecnologias para a gestão logística de coleta e distribuição de produtos para políticas públicas
Descrição do Produto
UNIVERSIDADE FEDERAL DO PARANA
EVERTON BORTOLINI
Uso de geotecnologias para a gestão logística de coleta e distribuição de produtos para políticas públicas
CURITIBA 2015
EVERTON BORTOLINI
Uso de geotecnologias para a gestão logística de coleta e distribuição de produtos para políticas públicas Projeto Final para o curso de graduação em Engenharia Cartográfica e de Agrimensura, Setor das Ciências da Terra da Universidade Federal do Parana. Orientadora: Professora Doutora Luciene Stamato Delazari
CURITIBA 2015
3 SUMARIO RESUMO......................................................................................................................4 1 INTRODUCAO..........................................................................................................5 2 OBJETIVOS..............................................................................................................7 2.1 OBJETIVO GERAL................................................................................................7 2.2 OBJETIVOS ESPECIFICOS..................................................................................7 3 DEFINIÇÃO E DESCRIÇÃO DOS USUÁRIOS........................................................8 4 MATÉRIAS E MÉTODOS........................................................................................11 4.1 MATÉRIAS...........................................................................................................11 4.1.1 QGIS..................................................................................................................11 4.1.2 PGADMIN (POSTGRESQL/POSTGIS)............................................................12 4.1.3 STRUCTURE QUERY LANGUAGE..................................................................12 4.1.4 PGROUTING.....................................................................................................13 4.1.5 OPENSTREETMAP...........................................................................................13 4.1.6 OSM2ROUTING................................................................................................13 4.1.7 PYTHON............................................................................................................13 4.1.8 PYQGIS.............................................................................................................14 4.1.9 PSYCONPG......................................................................................................14 4.1.10 PLUGIN BUILDER...........................................................................................14 4.1.11 QTCREATOR..................................................................................................14 4.1.12 GEDIT..............................................................................................................15 4.1.13 ARQUITETURA...............................................................................................15 4.2 MÉTODOS...........................................................................................................16 4.2.1 MODELO CONCEITUAL DO SISTEMA...........................................................16 4.3.2 ANÁLISES A SEREM REALIZADAS...............................................................17 4.3.3 DADOS DE ENTRADA.....................................................................................20 4.3.4 CRIAÇÃO DO BANCO DE DADOS.................................................................24 4.3.5 PROJETO E DESENVOLVIMENTO DAS INTERFACES.................................26 4.3.6 PROJETO CARTOGRÁFICO...........................................................................33 5 RESULTADOS........................................................................................................38 5.1 BANCO DE DADOS............................................................................................38 5.2 INTERFACE.........................................................................................................38 5.3 MAPAS TEMÁTICOS...........................................................................................47 6 CONCLUSÃO.........................................................................................................54 REFERENCIAS BIBLIOGRAFICAS..........................................................................56 APENDICE.................................................................................................................56
4 RESUMO Este trabalho tem por objetivo apresentar o desenvolvimento de um Sistema de Gestão Logística com suporte em Sistema de Informações Geográficas (SIG) que permita pequenos agricultores e a iniciativa pública local gestionar a logística dos projetos do Programa de Aquisição de Alimentos (PAA) de uma dada região, assim, permitindo definir a origem e destino de um conjunto de mercadorias de forma que o transporte seja realizado pelo trajeto de menor custo entre as propriedades produtoras e entendidas receptoras dos produtos. Para o desenvolvimento é fundamental considerar a ótica das tecnologias sociais, de maneira a produzir uma solução capaz de atender aos atores sociais. Além disso, a proposta tem impacto no como ferramenta de promotora de desenvolvimento local, suportando a organização interna e externa dos envolvidos, gerando melhoria de renda. Tal ferramenta pode ser inserida em outras políticas públicas. Palavras chaves: Banco de Dados Geográficos (BDG). Sistemas de Informações Geográficas (SIG). Logística.
5 1 INTRODUÇÃO O presente trabalho tem como objetivo de desenvolver um sistema para auxiliar a coleta e distribuição de alimentos para politicas públicas, tais como o Programa de Aquisição de Alimentos (PAA) e o Programa Nacional de Alimentação Escolar. O Programa de Aquisição de Alimentos da Agricultura Familiar (PAA) segunda a CONAB (2015a) foi desenvolvido pelo Conselho Nacional de Segurança Alimentar e Nutricional – CONSEA como parte do Fome Zero. Portanto, o mesmo visa prover às populações em situação de insegurança alimentar o acesso aos alimentos produzidos pela agricultura familiar, promovendo o fortalecimento de ambas partes. Para esse trabalho é fundamental conceituar dois atores importantes no processo, os produtores e as entidades. Os produtores referem-se aos agricultores responsáveis por produzir os alimentos, os mesmo são enquadrados na linha da agricultura familiar caracterizados pela pequena propriedade. As entidades são as instituições, caracterizadas por serem publicas com atendimentos a determinados públicos, as mesmas são representadas como escolas, hospitais, asilos entre outros, ou por órgãos que as gestão, como secretarias municipais ou estaduais. A construção de projeto para esses programas é de responsabilidade dos proponentes, os quais são as associações ou as cooperativas de produtores. Mas o que ocorre na maioria dos casos é que existe uma dependência do poder público (governos municipais, estaduais e outras instituições públicas). Nesta fase de construção do projeto é levada em consideração basicamente a oferta e demanda de produtos, ou seja, a relação produtores e entidades beneficiárias, desconsiderado aspectos como o planejamento da coleta e distribuição dos produtos, por parte dos produtores, e a identificação dos custos logísticos pelo poder público. Não havendo nenhum tipo de análise espacial sobre os dados de coleta e distribuição, o transporte destes alimentos entre as propriedades e as entidades não apresenta uma organização definida, e ao pensar-se a logística do PAA percebe-se que tratar o transporte de forma isolada, desconsiderando a disposição entre a origem e o destino, pode acarretar em acréscimo de custos ao produtor. Segundo Dowbor (2004): A informação além de ser um direito, a mesma bem organizada e bem disponibilizada constitui um poderoso instrumento de auto-
6 regulação na base da sociedade, pois todos os atores sociais, empresariais, secretários municipais, organizações comunitárias etc passam a tomar decisões mais bem informados (Dowbor: 2004: 137). Assim, o desenvolvimento de um sistema de informação é o primeiro passo para resolver as questões logísticas advindas do PAA, possibilitando essa maneira, iniciar o desenvolvimento de um método e de uma ferramenta para a gestão logística do PAA. Além disso, conforme o CSCMP (2003) “A logística é a parte da cadeia de suprimentos que planeja, implementa e controla o fluxo e o armazenamento”. Assim, por uma perspectiva de desenvolvimento local e da economia solidaria, busca-se o fortalecimento do abastecimento local e da circulação interna de produtos, pensando-se primeiramente na distribuição a nível local, com curtas distâncias, para em seguida, pensar nas maiores distâncias dentro e fora do município. O sistema logístico em desenvolvido tem como característica ser uma tecnologia de caráter social, assim deve ser construída a partir da realidade enfrentada pelos atores sociais, portanto, deve haver a interação deste atores com a ferramenta desenvolvida. Por fim, é fundamental agregar o suporte dos softwares livre na construção do sistema logístico. Portanto, tal tecnologia possui características inovadoras nesta perceptiva. Neste sentido, busca-se identificar os elementos a serem considerados na construção de uma solução para o planejamento e gestão logística para a agricultura familiar.
7 2 OBJETIVOS 2.1 OBJETIVO GERAL Desenvolver um sistema para auxiliar a coleta e distribuição de alimentos para politicas públicas. 2.2 OBJETIVOS ESPECIFICOS - Definir as análises necessárias, além dos dados de entrada sobre as centrais, propriedades, entidades e produtos; - Construir um banco de dados para armazenar de dados das propriedades e das entidades; - Desenvolver interface para a coleta dos dados das propriedades e das entidades; - Implementar análises espaciais para a coleta e distribuição dos produtos; - Implementar análise para cálculos dos fluxos e a roteirização no banco de dados; - Propor mapas temáticos para representar a distribuição e coleta dos alimentos.
8 3 DEFINIÇÃO E DESCRIÇÃO DOS USUÁRIOS Atualmente, os projetos de PAA são elaborados em formulários online através do software PAA.net, programa disponibilizado pela Companhia Nacional de Abastecimento (CONAB) (CONAB, 2015b). O mesmo requer o preenchimento de dados dos produtores e das entidades, tais como responsáveis, tipos e quantidades de produtos coletados/entregues. Tais interfaces, da maneira como são organizados, não permitem qualquer planejamento por parte dos executores do projeto, nem ao menos existe um programa desenvolvido para isso. De forma a suportar o desenvolvimento de projetos e como material auxiliar para entender a gestão do PAA existe o Manual Operativo (CONAB, 2014), sendo que o mesmo detalha os atores envolvidos nos projetos, como Unidades Gestoras, Unidades Executoras, Beneficiário Fornecedor, Beneficiário Consumidor, e suas atribuições durante o processo. Além disso, apresenta as etapas de concepção, elaboração e execução do PAA. O texto é abordado de maneira técnica, intercalada com trechos com uma linguagem mais simples e direta. No Manual Operativo do PAA, tópicos como logística (muitas vezes usados erradamente para designar o transporte, o qual é apenas um tópico da logística) e armazenamento são seguidamente citados, deixando a cargo das chamadas unidades gestoras (Prefeitura e Governo do Estado, principalmente) o planejamento, e por consequência aos Beneficiários Fornecedor (produtores) a execução de tais tópicos. Além disso, cita-se seguidamente a definição da produção conforme a demanda. Em determinado momento o referido manual relata que “a proposta de participação deve ser fruto de um criterioso planejamento no que diz respeito à demanda de alimentos, à oferta, à logística e ao armazenamento” (CONAB: 2014: 38). Contudo, a CONAB (2014) não desenvolve método para isso, tão pouco uma ferramenta. Assim a responsabilidade de planejar a coleta e a distribuição é repassada aos níveis administrativos de menor escala e menos estruturados (Governo Municipal e Governo Estadual) ou mesmo aos produtores. Além disso, Razzolini (2007) estima que os custos logísticos representam 30% dos custos totais. Portanto, os custos logísticos representam uma parte considerável do custo de produção dos produtos, sendo que no caso do PAA os mesmos são desembolsados diretamente pelos produtores sobre seus ganhos com a venda. Assim,
para
o
desenvolvimento
de
um
Sistema
Logístico
está
9 acompanhando o planejamento do projeto do PAA da Associação dos Produtores Rurais de Tunas do Paraná (APROTUNAS) compreendendo 29 produtores. A mesma está localizada no município de Tunas do Paraná e está em processo incubação pela Incubadora Tecnológica de Cooperativas Populares de Universidade (ITCP-UFPR). Outras associações envolvidas no mesmo projeto estão localizadas nos municípios de Cerro Azul e Doutor Ulysses, tais associações são a Macuco, a Vicentina e a Teixeira compreendendo 39 produtores. As entidades envolvidas no projeto são as escolas das Secretarias da Educação Municipais e as Ações Sociais dos municípios de Cerro Azul, Tunas do Paraná e Bocaiuva do Sul e o Mesa Brasil de Curitiba – PR compreendendo mais de 20 unidades atendidas espalhadas por várias regiões dos municípios citados. A figura 1 traz a relação dos municípios envolvidos apresentados em um mapa. Portanto, a área de estudo para o desenvolvimento do protótipo do sistema de gestão logística de produtos para o PAA compreende os municípios de Tunas do Parana, Cerro Azul, Doutor Ulysses, Bocaiuva do Sul e Curitiba. Assim, exceto Curitiba, todos os municípios fazem parte do Vale do Ribeira, região que caracteriza-se por municípios de baixo Índice de Desenvolvimento Humano (IDH), baixa renda per capita e economia predominante de pequenas propriedades com dedicação a agricultura familiar em contraste com propriedade de exploração de madeira (IPARDES, 2007 e IBGE, 2015a). Assim, apresenta-se a necessidade de intervenções de políticas públicas para melhoria econômica e social. Assim, para a agricultura, aparecem as políticas como o Programa de Aquisição de Alimentos (PAA), o Programa de Nacional de Alimentação Escolar (PNAE) entre outras.
10
FIGURA 1: LOCALIZAÇÃO DOS MUNICÍPIOS NO QUAL LOCALIZAM-SE AS PROPRIEDADES E ENTIDADES ENVOLVIDAS NO PROJETO COLETIVO PARA O PROGRAMA DE AQUISIÇÃO DE ALIMENTOS. FONTE: AUTOR, 2015.
11 4 MATERIAIS E MÉTODOS Em uma proposta de qualquer solução que envolva atores sociais não hegemônicos é essencial o conhecimento dos conceitos de tecnologias sociais. Os pesquisadores Otero & Jardim (2004) definem tecnologia social como: “Conjunto
de
técnicas
metodológicas
transformadoras,
desenvolvidas e/ou aplicadas na interação com a população e apropriadas por ela, que representam soluções para inclusão social e melhoria na condição de vida. Logo, a tecnologia deve ser desenvolvida com a comunidade, fazendo sua modelagem conforme as reais necessidades e da lógica da comunidade, e deve ser desenvolvida para a comunidade, de maneira a ser entendidas por todos os seus usuários, a fim de oportunizar o uso de maneira independente .
(Otero & Jardim: 2004: 130). Para o desenvolvimento de qualquer ferramenta da chamada tecnologia social é importante utilizar ferramentas livres, pois os desenvolvedores e os usuários podem personalizar tais ferramentas as suas necessidades, além de ter independências financeiras como explanado por Crampton (2005). Os programas OpenSource ou de licença livre são aqueles oferecidas sob a licença da Fundação General Public License (GNU) de Software Livre. 4.1 MATERIAIS 4.1.1 QGIS O QGIS, segundo o OSGeo (2015) é um Sistema de Informações Geográficas de código aberto sobre licença General Public License (GNU) que opera em vários sistemas operacionais. No que tange o desenvolvimento de ferramentas, tal SIG possibilita a criação de extensões. Tais extensões possibilitam realizar processos que não foram implementados no
QGIS ou automatizar
determinados conjuntos de atividades. As extensões são comumente chamadas de plugin ou complementos e podem ser instaladas diretamente pelo menu Complementos. A versão usada do QGIS no desenvolvimento deste sistema foi a
12 2.8, contudo qualquer versão 2.0 ou superior é habilitada para executá-lo. O desenvolvimento de plugin para o QGIS é possível com o uso da linguagem de programação Python 2.7 somado ao uso do programa QTCreator para a criação da interface. Os dois itens citados serão brevemente descritos em capítulos 4.1.5 e 4.1.6. 4.1.2 POSTGRESQL/POSTGIS (PGADMIN) O PgAdmin (Postgresql, 2015) é uma interface gráfica do usuário do PostgreSQL, que é um Sistema Gerenciador de Banco de Dados (SGBD) que permite criação, edição e consulta em um banco de dados. A extensão espacial do PostgreSQL que permite trabalhar com banco de dados geográficos é nominada de PostGIS. Para o gerenciamento do banco de dados geográfico utilizam-se de códigos em linguagem SFA-SQL(ISO 19125) (ISO, 2004) na linha de comando do PgAdmin, que podem ser usados para processos mais específicos ou não automatizados como a criação de consultas. Contudo, o PgAdmin conta com funções já implementadas as quais estão localizadas nos menus e nas propriedades dos itens deste programa; seu foco é ser usado para realizar processos gerais ou simples, como criação de banco de dados, das tabelas e de seus atributos. Por fim, o Postgresql é um SGBD aberto, sendo que suas funcionalidades atendem às necessidades de projetos como o desenvolvimento de banco de dados geográfico com custos acessíveis, pois o mesmo pode ser instalado em qualquer computador sem a necessidade de pagamento de licenças. 4.1.3 STRUCTURED QUERY LANGUAGE (SQL) O SQL (Chamberlin et al, 1981) é uma linguagem de pesquisa declarativa para banco de dados relacionais. Tal linguagem foi criada na década de 70 nos laboratórios da IBM no projeto SystemR para a viabilização do modelo relacional de E. F. Cood. O SQL permite definição, controle, transação e consulta de dados em seus bancos. O SFA-SQL (ISO 19125) (ISO, 2004) criou um padrão de banco de dados geográficos que permitiu o uso de comandos SQL em feicoes.
13 4.1.4 PGROUTING O pgRouting (PgRouting, 2015) é uma extensão do Postgresql/PostGIS que permite calcular rotas a partir de dados espaciais vetoriais de malha viária, incluindo feições de linha as quais representam as ruas e nós ou feições pontuais que representam os cruzamentos. A roteirização é possível a partir de consultas com dados de localização de pontos de interesse sobre os dados da malha viária. Os algoritmos de roteirização implementados nesta extensão são o Algoritmo de Johnson, Algoritmo de Floyd-Warshall, Algoritmo de Dijkstra, e o Multipath routing caixeiro viajante. 4.1.5 OPENSTREETMAP O
OpenStreetMap
(OpenStreetMap,
2015)
é
uma
plataforma
de
mapeamento colaborativo aberto inspirada na Wikipedia, no qual é possível editar qualquer informação geográfica em qualquer parte do mundo. Além disso, as informações contidas nesta plataforma podem ser usadas por quaisquer pessoas para as mais variadas finalidades. Portanto, o conteúdo do OpenStreetMap torna-se interessante em projetos que necessitam de informações abertas e de fácil acesso e custo, como é o projeto de sistema logístico desenvolvido. 4.1.6 OSM2PGROUTING O OSM2PgRouting (OpenStreetMap, 2015) é um programa para conversão da base da cartográfica advinda do OpenStreetMap para um formato apto para trabalhar com linguagem SQL com suporte do PgRouting. 4.1.7 PYTHON O Python (Python, 2015) é uma linguagem de programação desenvolvida originalmente por Guido van Rossum e lançada em 1991. A mesma é considerada uma linguagem de alto nível, interpretada, imperativa, orientada a objetos, funcional. Nos dias atuais possui um modelo de desenvolvimento comunitário, aberto e gerenciado pela organização sem fins lucrativos Python Software Foundation. A
14 linguagem Python é adotada na implementação de várias funções em Sistemas de Informação Geográfica, incluindo o QGIS e ArcGIS. 4.1.8 PYQGIS O PyQGIS (QGIS, 2015a) é uma biblioteca Python para desenvolvimento de aplicações para QGIS. As funcionalidades desta biblioteca no QGIS incluem criar e usar plugins, customizar aplicações baseadas em QGIS API e usar linhas de comando no Python console no QGIS.
4.1.9 PSYCOPG O Psycopg (PSYCOPG, 2015) é uma adaptação para Python do PostgreSQL. A função desta biblioteca é possibilitar mesclar códigos em linguagem Python com comandos SQL. 4.1.10 PLUGIN BUILDER O Plugin Builder (QGIS, 2015b) é um complemento ou plugin do QGIS que auxilia na criação de um modelo básico (template) para construção de outros plugins para o próprio QGIS. Entre os arquivos criados pelo Plugin Builder estão o que permite a edição do interface do plugin e o arquivo que permite a programação, em Python, das funcionalidades da mesma. 4.1.11 QTCREATOR O QtCreator (Qt, 2015) é um programa que permite a confecção de interfaces para os programas através da implementação de widgets. Além disso, é possível editar a interface diretamente no código, através de linguagens de programação tais quais a C++, C# ou Python. Somado ao que foi citado, o QtCreator é um programa livre, o que facilita o acesso e reduz custos para os projetos que o necessitam. Por fim, as funcionalidades disponíveis são comparáveis às de softwares proprietários e atendem às necessidades.
15 Para o desenvolvimento da interface dos plugins para QGIS é recomendado o uso do QtDesigner, uma dos programas do pacote do QtCreator, pois a sua biblioteca Python, a PyQt, é compatível com a biblioteca Python do QGIS, a PyQGIS (QGIS, 2015a). 4.1.12 GEDIT O Gedit (GNOME, 2015) é um editor de textos para os sistemas operacionais Linux. A principais funcionalidade que permitem seu uso com editor para códigos Python são suas capacidades de interpretação de sintaxe e numeração de linhas. Porém o Gedit não é similar ao IDLE, pois o mesmo não possui capacidade de compilação ou execução de códigos, assim, necessitando do Python Terminal do QGIS para tal tarefa. 4.1.13 ARQUITETURA A arquitetura do sistema (figura 2) tem como objetivo demostrar as ligações entre as componentes do sistema logístico.
FIGURA 2: ARQUITETURA DO SISTEMA LOGISTICO. FONTE: AUTOR, 2015.
16 4.2 MÉTODOS 4.2.1 MODELO CONCEITUAL DO SISTEMA A função da primeira etapa é elencar as análises necessárias a fim de obter a solução desejada ao problema, além de definir os possíveis dados de entrada sobre as propriedades, entidades e produtos. Os dados de entrada considerados dados básicos para a elaboração de um projeto para o Programa de Aquisição de Alimentos, incluem dados dos produtores, das entidades, os tipos de produtos e suas produções e demandas. No desenvolvimento de tecnologias sociais, baseado no que Sheppard et al (1999) sugere, e assim combinar as experiências práticas dos usuários do sistema com a execução de projetos de PAA com a expertise de programadores e indivíduos qualificados no estudo de SIG e sociedade. Nesta abordagem, o posicionamento da universidade é de fonte do profissional com conhecimento o qual vai ajudar a comunidade em uma área de conhecimento em que a mesma não domina no momento. Em contrapartida, a comunidade cede o conhecimento prático sobre o qual o especialista vai desenvolver a tecnologia e acompanhar o seu desenvolvimento. O Diagrama de Caso de Uso inclui universidade e a comunidade sobre a abordagem do Sheppard et al (1999), a Universidade Federal do Paraná fica responsável pela atualização do sistema por meio de modificação e correção de erros. Quanto aos dados é possível inseri-los, no caso do OpenStreetMap, por qualquer pessoa envolvida ou não com o projeto. O demais dados são passiveis de ser inseridos, processados e visualizados pelos membros da comunidade (produtores, técnicos extensionista e entidades) e pelos membros da universidade. O Diagrama de Caso de Uso pode ser visto na figura 3.
17
FIGURA 3 – DIAGRAMA DE CASO DE USO. FONTE: AUTOR, 2015. 4.3.2 ANALISES A SEREM REALIZADAS Os dados requeridos pelo PAA.net não consideram atributos espaciais, não permitindo que a própria CONAB faça analises espaciais dos seus dados. Portanto, para funcionamento de um sistema de informação geográfica é fundamental que
18 haja dados espaciais dos atores envolvidos. Para o sistema logístico é fundamental definir quanto cada produtor vai produzir de cada produto de forma a criar uma solução que equilibre as quantidades, demandadas e produzidas, de maneira a minimizar os deslocamentos para a entrega destes produtos. O equilíbrio entre demanda e oferta de produtos deve considerar as sazonalidades de produção para a região e para os costumes dos produtores e o período de consumo dos produtos pelas entidades, da perecibilidade o qual vai determinar a época, a frequência e a distância necessárias para a entregas. Portanto, o modelo de solução logística deve primeiramente considerar os produtos dos quais os produtores estão culturalmente acostumados a produzir. A coleta é realizada por meio de diagnostico rural participativo. Esta pratica vem a incentivar a elaboração de cardápio baseado em produtos locais. Assim, o sistema de informação é alimentado com dados informados pelos beneficiários fornecedores (agricultores), a partir dos seus anseios. Na sequencia deve-se considerar os produtos com potencial de produção em determinada área, mas que ainda não são produzidos pelos produtores, porém, podem fazer parte dos produtos demandados. Tais produtos devem ser identificados pelos técnicos de extensão do município. A disposição destes produtos possibilita um cardápio mais variado e possibilita uma nova alternativa de produção para os produtores. Nas etapas iniciais os dados coletados nos produtores são descritos, não sendo definidas quantidades. Os mesmos são considerados pelas entidades na definição final do cardápio. A demanda deve ser balizada pela quantidade de pessoas atendidas e seu perfil. Além disso, é importante conhecer a distribuição espacial das entidades e produtores. Deve-se conhecer os percussos e os custos relativos a este percurso. Tais fatores citados vão definir quais produtos devem ser produzidos e consumidos em uma mesma região e qual a viabilidade de seu transporte conforme o volume do mesmo. A espacialização delimita casos onde a viabilidade do transporte dá-se entre produtores e entidade de diferente municípios. Além disso, espacializar visa identificar os grupos de produtores que estão unidos ou que podem-se unir para facilitar a gestão logística de maneira a criar um entreposto (hub). A partir da quantidade de produtos a serem produzidos é possível definir os
19 fluxos, entre um produtor e uma entidade ou entre uma central e uma entidade, e a quantidade de produto a ser transportado em cada um destes fluxos. A viabilidade de um determinado fluxo é definido pelo volume do veiculo que será responsável pelo transporte e a frequência necessária para esse transporte. Retornando aos conceitos implementados na logística, o deslocamento de mercadorias e o seu volume é chamado comumente de fluxo. Para Razzolini (2007) podemos afirmar que logística é fluxo, sendo os três principais fluxos logísticos: o físico, o de informação e o financeiro. O nosso interesse neste trabalho é trata do fluxo físico. Em termos práticos do fluxo físico, o qual é aplicado no transporte, Razzolini (2007) exemplifica que os fluxos podem ser representados por toneladas por quilômetros útil (TKU) ou em toneladas por unidade de tempo (TUT – t/dia, t/semana, t/quinzena, t/mês). Para cargas de menor peso, mas grande volume, são mensuradas em metros cúbicos por unidade de tempo (MCUT – m3/dia, m3/semana, m3/quinzena, m3/mês). Quando as cargas são transportadas de forma unitizada é possível medir os fluxos nessas unidades (paletas/dia, paletas/semana, contêineres/dia) Tais fluxos (físico, de informação e financeiro) citados são percebidos na execução de projetos de PAA, portanto um sistema logístico deve prever esses fluxos. Na logística no modelo convencional os fluxos são de longa distancia, no caso do PAA, deve buscar os fluxos de curta distância, como apresentado no Manual Operativo do PAA. Por fim, são definidas as rotas mais viáveis, a qual é a de menor custo e a frequência ideal a fim de atender as entidades com a maior frequência possível, a fim de entregar um produto de melhor qualidade e sempre fresco. As analises necessárias estão descritas na figura 4, sendo a analise de distribuição de produtos desenvolvidas neste trabalho e a analise dos fluxos e roteirização idealizadas, porem não desenvolvidas ainda.
20
FIGURA 4: ANALISES NECESSÁRIAS PARA O SISTEMA LOGÍSTICO. FONTE: AUTOR, 2015. De maneira prática e simplificada a análise para a geração dos fluxos contemplou uma consulta as distancias entre produtores e entidades ordenando-as pelas de menor valor. Apos, a ordem definida impõe quais são as primeiras entidades atendidas e por qual produtor, conforme a disponibilidade no produtor. Este processo acontece para cada produto. Por fim, o mesmo encerra-se quando todas as entidades estiverem atendidas. 4.3.3 DADOS DE ENTRADA A fim de executar as analises necessárias é fundamental a organização das informações, pois o mesmo é o primeiro passo de qualquer planejamento. Assim, é interessante que todas as informações sobre a demanda das entidades e a produção de alimentos ou potencialidades dos produtores estejam armazenadas de maneira organizada de forma que os circuitos locais e regionais de comercialização sejam efetivos. Além disso, é preciso utilizar-se da própria organização coletiva dos produtores, tais como sedes de cooperativas, associações de produtores ou mesmo de associações comunitárias como ponto de concentração ou entreposto (hub) para auxilio do planejamento logístico, tanto no âmbito das análises, da apresentação dos resultados, e por consequência da própria execução do próprio planejamento logístico. Ao tipo de estrutura proposta denomina-se central no sistema logístico.
21 Portanto, de maneira resumida, os dados a serem considerados, por parte dos produtores são os atributos como o nome, sua localização e a qual associação ou cooperativa o mesmo está pertencendo, nominado de central. Sobre as entidades é importante seu nome e localização. Para os produtos é importante seu nome, preço e a distancia no qual é interessante o transporte conforme a frequência de entrega sua perecibilidade e o volume comumente transportado. Os produtos não são considerados espaciais e estão referenciados pela tabela disponibilizada pela CONAB (CONAB, 2015b). No que tange a produção e a demanda deve ser considerado se o produto é produzido ou tem potencial de produção na propriedade e o quanto é demandado na entidade, além disso deve ser considerado o período de demanda e de produção de cada produto. A coleta das coordenadas dos atores pode ser realizada com a geotecnologia do Global Navigation Position Satelite System (GNSS) por meio do uso de receptores ou navegadores. Quanto a coleta de dados sobre a produção dos produtores é interessante uma metodologia baseada no Guia Pratico de Diagnostico Rural Participativo. Em tal publicação, Verdejo (2007: 6) conceitua: “O Diagnóstico Rural Participativo (DRP) é um conjunto de técnicas e ferramentas que permite que as comunidades façam o seu próprio diagnóstico e a partir daí comecem a autogerenciar o seu planejamento e desenvolvimento”. Portanto, o mesmo é auxiliar no processo de gestão logística. O esquema do que foi descrito encontra-se na figura 5.
22
FIGURA 5 – ATRIBUTOS PARA OS DADOS DE ENTRADA DOS PRODUTORES, ENTIDADE E CENTRAIS. FONTE: AUTOR, 2015. Outros dados de interesse são a localização das feições como as estradas e ruas localizadas nos municípios de Tunas do Paraná, Cerro Azul, parte de Doutor Ulysses, Bocaiuva do Sul e Curitiba. As estradas e ruas são adquiridas através de digitalização dos dados não existentes somado as já disponíveis no serviço de mapeamento colaborativo OpenStreetMap. Houve necessidade da digitalização dos dados
espaciais
neste
trabalho,
pois
contatou-se
que
nos
países
em
23 desenvolvimento os mesmos são deficitários quanto a sua quantidade em plataformas de informação geográfica voluntário, tal como o próprio OpenStreetMap, a qual é uma fonte gratuita para este tipo de dado. Camboim et al (2015) realizaram estudos sobre a disponibilidade de dados geográficos no Brasil e afirmaram que foi observado que a distribuição é concentrada, principalmente em área com grande população, tais como Curitiba, sendo regiões com baixa densidade populacional e baixo Índice de Desenvolvimento Humano (IDH) deficitárias espacialmente em quantidade de dados. Além disso, o próprio mapeamento oficial possui uma quantidade de dados aquém do desejável, como passagem apresentada para regiões como o Vale do Ribeira. A estrutura dos dados advindos do OpenStreetMap ira ser detalhados no capitulo sobre Criação do Banco de Dados por envolver parte da estrutura do mesmo. Além disso, como meio de referencia visual na leitura dos mapas posteriores a analise dos dados é importante considerar de divisão politica da região, assim fazse necessário os limites municipais disponibilizada pelo Instituto Brasileiro de Geografia e Estatística (IBGE) por FTP por meio de seu site oficial (IBGE, 2015a). Os dados do IBGE com a malha municipal contem atributos do tipo nome, código de identificação atribuído pelo próprio IBGE, além da geometria dos municípios, o que inclui os seus limites. A caracterização técnica dos dados de entrada são o uso do sistema de referencia WGS-84, compatível com SIRGAS (IBGE, 2015b), tal como nos dados coletados por receptor de GPS do tipo de navegação e com a base cartográfica do OpenStreetMap. Além disso, o SIRGAS é o sistema de referencia da malha municipal disponibilizada pelo IBGE. A malha viária extraída do OpenStreetMap está no formato OSM, o qual deve ser inserido no banco de dados geográficos com uso da extensão OSM2POSTGRES conforme linha de comando indicada na quadro 1 a qual deve ser digitada no terminal (Ubuntu) ou CMD (Windows). A malha municipal está no formato Shapefile, o qual também deve ser inserida no banco de dados geográficos.
24 osm2pgrouting -file /home/everton/parana_estrada.xml -conf ~/osm2pgroutingmaster/mapconfig.xml -dbname EcosolLog -user postgresql94 -host localhost -passwd ***** -clean QUADRO 1: CÓDIGO PARA ADICIONAR A CAMADA OPENSTREETMAP NO BDG. FONTE: AUTOR, 2015. A escala máxima para os dados do OpenStreetMap é usualmente de 1:8000, segundo o que é referenciado na wiki do site de mapeamento colaborativo (OpenStreetMap, 2015) para a visualização de estradas. Os dados disponibilizados pelo IBGE para a malha municipal estão na escala de 1:250000. Para os dados de localização dos produtores e das entidades estão ligados a qualidade do GPS de navegação, assim estimando-se uma precisão 10 metros na coleta dos das coordenadas e considerando a percepção visual de 0,2 mm do olho humano convenciona-se o uso da escala de 1:50000. As informações estão descritas de maneira sintetizada no quadro 2.
Dado
Fonte
Formato
Data
Escala
Sistema de Referencia
Produtores
DRP/GPS
Texto
Jun/2015
1:50000
WGS-84
Entidades
DRP/GPS
Texto
Nov/2015
1:50000
WGS-84
Centrais
DRP/GPS
Texto
Jun/2015
1:50000
WGS-84
Malha municipal
IBGE
Shapefile (SHP)
2010
1:250000
SIRGAS
Malha OpenStreetMap OSM Nov/2015 1:8000 WGS-84 viária QUADRO 2: SÍNTESE DAS INFORMAÇÕES SOBRE OS DADOS DE ENTRADA. FONTE: AUTOR, 2015. IBGE, 2015. OPENSTREETMAP, 2015. 4.3.4 CRIAÇÃO DO BANCO DE DADOS Esta etapa da metodologia tem por objetivo implementar um Banco de Dados para o sistema logístico considerando a estrutura elencada no capitulo 4.3.3. Assim, para a estruturação de um banco de dados geográfico é fundamental o entendimento do paradigma dos quatro universos apresentado por Vinhas (2005). A criação do banco de dados geográfico (BDG) foi suportado pelo PostgreSQL usando
25 a interface do PgAdmin utilizando-se de funções já implementadas no software, somada ao uso de códigos em Structured Query Language (SQL). Por fim, a versão usada a 9.3 do Postgresql e a 2.1 do PostGIS no PgAdmin3. Para sistematização do mesmo foi confeccionado um Diagrama de classe, o qual permite visualizar todas as tabelas, suas chaves principais e estrangeiras, seus demais atributos, além do tipo de dado relativo aos mesmos. As conexões entre as tabelas são chamadas de chaves estrangeiras. Tal diagrama de classe é apresentado na figura 6. As tabelas dos produtores, entidades e centrais possuem um atributo espacial. Em contrapartida, as tabelas produto, produto produzido e produto demandado não são tabelas com atributos espaciais. Para o desenvolvimento do banco de dados foi realizada a conexão com o servidor. Assim, pode-se primeiramente criar o banco de dados do sistema logístico. Com o banco de dados criado foi necessário adicionar as extensões do PostGIS (permite uso de atributos espaciais) e do PgRouting (permite a roteirização). A adição posterior dos dados de estrada advindos do arquivo OSM do OpenStreetMap provem um incremento na estrutura do banco de dados incluído um grupo de tabelas inter-relacionadas, no qual há duas delas com atributos espaciais (way e way_vertices_pgr) as quais são a representação dos trechos de estradas (way) e de suas intersecções (way_vertices_pgr). O diagrama de classe do arquivo OSM no banco de dados é apresentado na figura 6.
26
FIGURA 6 – DIAGRAMA DE CLASSES FONTE: AUTOR, 2015.
27 4.3.5 PROJETO E DESENVOLVIMENTO DAS INTERFACES Para desenvolver interface para a coleta dos dados das propriedades e das entidades, é necessária a elaboração de uma interface apropriada para usuário, no caso, os agricultores e técnicos da Empresa de Assistência Técnica e Extensão Rural do Parana (EMATER-PR). A interface foi desenvolvida em QtCreator com uso da linguagem de programação Python. A mesma permitirá a inserção dos dados relativos ao projeto no banco de dados, além disso, permitir o acesso dos dados já existentes no mesmo. A interface vai permitir inserir todos os dados relativos as propriedades e as entidades, e suas produções e consumos, respectivamente. A figura 7 permite a visualização do painel de edição da interface (centro) incluindo as ferramentas para adição de widgets (a esquerda), as ferramentas de edição destes widgets (a direita) e ferramentas de configurações (acima).
FIGURA 7 – INTERFACE DO QT DESIGNER PARA DESENVOLVIMENTO DE INTERFACES. FONTE: AUTOR, 2015. Para a confecção da interface é necessário o uso de widget tais como os indicados no quadro 3.
28 Widget
Função
Push Button
Ativar determinada ação
Check Box
Selecionar/Não selecionar determinado atributo
Button Box
Autorizar/Cancelar determinada ação
Table Widget
Apresentar dados no formato de tabela
Tool Box
Apresentar abas verticais
Combo Box
Selecionar determinado item de uma lista
Line Edit
Inserir um determinado texto
Date Edit Editar uma data QUADRO 3: WIDGET USADAS NO DESENVOLVIMENTO DA INTERFACE. FONTE: AUTOR. Em paralelo com a construção da interface programa-se com o uso da linguagem Python as funções dos widgets implementados. A figura 8 apresenta parte do código implementado para execução de determinada tarefa a partir de determinada ação sobre o widget. O código completo está disponibilizado na plataforma Github em: .
FIGURA 8 – INTERFACE DO CÓDIGO DA INTERFACE. FONTE: AUTOR, 2015. A estrutura da interface foi dividida em duas partes (dado esquerdo e lado
29 direito). Ambas partes são formadas por abas verticais, o qual por sua vez são formada por um segundo nível de abas verticais. Por fim, cada aba comporta um conjunto de widgets. O quadro 4 apresenta o layout básico da interface do sistema logístico com as divisões principais. OS quadros 5, 6 e 7 apresentam todos os widgets a serem implementados na interface além do seu tipo e função.
Lado esquerdo: Contém as tabelas. Não Lado direito: Contém os elementos de permite a inserção de dados, apenas a interação do usuários através de consulta. widgets. Contém as abas de Dados de entrada e Contém as Abas de Inserir, Editar e dados processados. Processar e demais abas contidas nas mesmas.
QUADRO 4: LAYOUT BÁSICO DA INTERFACE FONTE: AUTOR.
30 Aba de nível 1 (Tool Box)
Aba de nível 2 (Tool Box)
Widget
Função
Inserir
Central
Line Edit
Nome central
Line Edit
Latitude central
Line Edit
Longitude central
Push Button
Adicionar
Line Edit
Nome produtor
Line Edit
Latitude produtor
Line Edit
Longitude produtor
Combo Box
Nome central
Push Button
Adicionar
Combo Box
Nome produtor
Combo Box
Nome produto
Check Box
Produto produzido
Check Box
Produto potencial
Date Edit
Data de inicio
Date Edit
Data de fim
Push Button
Adicionar
Line Edit
Nome entidade
Line Edit
Latitude entidade
Line Edit
Longitude entidade
Push Button
Adicionar
Combo Box
Nome produtor
Combo Box
Nome produto
Line Edit
Produto (quantidade)
Date Edit
Data de inicio
Date Edit
Data de fim
Produtor
Produtor - produto
Entidade
Entidade - produto
Push Button Adicionar QUADRO 5: WIDGETS A SEREM IMPLEMENTADOS NA PARTE DIREITA DA INTERFACE (PARTE 1). FONTE: AUTOR, 2015.
31 Aba de nível 1 (Tool Box)
Aba de nível 2 (Tool Box)
Widget
Função
Editar
Central
Combo Box
Nome central
Line Edit
Latitude central
Line Edit
Longitude central
Push Button
Atualizar
Push Button
Excluir
Combo Box
Nome produtor
Line Edit
Latitude produtor
Line Edit
Longitude produtor
Combo Box
Nome central
Push Button
Atualizar
Push Button
Excluir
Combo Box
Nome produtor
Combo Box
Nome produto
Check Box
Produto produzido
Check Box
Produto potencial
Date Edit
Data de inicio
Date Edit
Data de fim
Push Button
Atualizar
Push Button
Excluir
Combo Box
Nome entidade
Line Edit
Latitude entidade
Line Edit
Longitude entidade
Push Button
Atualizar
Push Button
Excluir
Combo Box
Nome produtor
Combo Box
Nome produto
Line Edit
Produto (quantidade)
Date Edit
Data de inicio
Date Edit
Data de fim
Push Button
Atualizar
Push Button
Excluir
Produtor
Produtor - produto
Entidade
Entidade - produto
Gerar relatórios Push Button Gerar relatórios QUADRO 6: WIDGETS A SEREM IMPLEMENTADOS NA PARTE DIREITA DA INTERFACE (PARTE 2). FONTE: AUTOR, 2015.
32 Aba de nível 1 (Tool Box)
Aba de nível 2 (Tool Box)
Widget
Função
Dados de entrada
Central
Table Widget
Central
Produtor
Table Widget
Produtor
Produtor - produto
Table Widget
Produtor - produto
Entidade
Table Widget
Entidade
Entidade - produto
Table Widget
Entidade - produto
Produto
Table Widget
Produto
Produto – entidade por produto
Table Widget
Produto – entidade por produto
Produto – entidade
Table Widget
Produto – entidade
Central – entidade
Table Widget
Central – entidade
Produto - Produtor
Table Widget
Produto - Produtor
Produto - Entidade
Table Widget
Produto - Entidade
Relatórios
Produto - Central Table Widget Produto - Central QUADRO 7: WIDGETS A SEREM IMPLEMENTADOS NA PARTE ESQUERDA DA INTERFACE. FONTE: AUTOR, 2015. As abas da parte esquerda serão sincronizadas com a abas da parte direita a fim de prover uma melhor experiencia de uso de modo que a mudança nas abas de uma parte provoque a mudança automática da outra. Assim, o quadro 8 apresenta as sincronização entre as abas, como já citado.
33 Parte
Esquerda
Sincroniza com (e vice e versa)
Parte
Direita
Aba de nível 1
Aba de nível 2
↔
Dados de entrada
Central
↔
Produtor
↔
Produtor
Produtor produto
↔
Produtor produto
Entidade
↔
Entidade
Entidade produto
↔
Entidade produto
Aba de nível 1
Aba de nível 2
↔
Dados de entrada
Central
↔
Produtor
↔
Produtor
Produtor produto
↔
Produtor produto
Entidade
↔
Entidade
Aba de nível 1 Aba de nível 2 Inserir
Central
Aba de nível 1 Aba de nível 2 Editar
Central
Entidade ↔ Entidade produto produto QUADRO 8: SINCRONIZAÇÃO ENTRE AS ABAS CONTIDAS NA INTERFACE. FONTE: AUTOR, 2015. 4.3.6 PROJETO CARTOGRÁFICO O projeto cartográfico contempla a visualização cartográfica dos dados processados. Assim, foram considerado a representação dos dados dos produtores, das entidades, das centrais e dos fluxos de produtos dos produtores para as entidades e dos fluxos das centrais para as entidades. As informações de linguagem cartográfica para o projeto estão contidas no quadro 9 e seguem a definição de Slocum (2008).
34 Dado Atributo representado Primitiva gráfica processado (unidade)
Nível de Medida
Variável visual
Produtores/ Entidades/C entrais
Nominal
Tom de Cor
Tipo
Feição pontual
Produtores
Produto - quantidade Feição pontual produzida (Kg)
Numérica
Tamanho
Entidades
Produto - quantidade Feição pontual demandada atendida (Kg)
Numérica
Tamanho
Centrais
Produto - quantidade Feição pontual produzida (Kg)
Numérica
Tamanho
Fluxo Produtor Entidade
Produto – quantidade (Kg)
Feição linear
Numérica
Tamanho
Fluxo Produtor Entidade
Nome do produtor
Feição linear
Nominal
Tom de Cor
Fluxo Central Entidade
Produto – quantidade (Kg)
Feição linear
Numérica
Tamanho
Fluxo Central Entidade
Nome do produtor
Feição linear
Nominal
Tom de Cor
Malha Municipal
-
Feição Zonal
Nominal
Tom de Cor
Malha viária Feição linear Nominal Tom de Cor QUADRO 9 : INFORMAÇÕES DE LINGUAGEM CARTOGRÁFICAS DOS DADOS A SEREM REPRESENTADOS. FONTE: AUTOR, 2015. O projeto cartográfico contempla primeiramente a definição das escalas no qual as feições devem aparecer. O mesmo tem importância por melhorar a apresentação e tornar mais clara a leitura. O intervalo de escala definida limitam um valor de escala máxima (1:10000) e mínima (1:3000000). Além disso, ha uma divisão nas informações visíveis em dois níveis. O intervalo de escala maior (entre 1:10000 e 1:100000) permite visualizar os dados 'relativos aos fluxos entre entidade e produtores. O intervalo de escala menor (entre 1:100000 e 1:3000000) permite visualizar os dados relativos aos fluxos entre centrais e entidades. Os detalhes estão descritos no quadro 10.
35 Dado processado
Atributo representado (unidade)
Escala Mínima
Escala Máxima
Produtores
Produto - quantidade produzida (Kg)
1:100000
1:10000
Entidades
Produto - quantidade demandada atendida (Kg)
1:3000000
1:10000
Centrais
Produto - quantidade produzida (Kg)
1:3000000
1:100000
Fluxo Produtor Entidade
Produto – quantidade (Kg)
1:3000000
1:10000
Fluxo Produtor Entidade
Nome do Produtor
1:3000000
1:10000
Fluxo Central Entidade
Produto – quantidade (Kg)
1:3000000
1:10000
Fluxo Central Entidade
Nome do Produtor
1:3000000
1:10000
Malha Municipal
-
1:10000000
1:10000
Malha viária 1:3000000 1:10000 QUADRO 10: REPRESENTAÇÃO DOS DADOS A SEREM APRESENTADOS CONFORME A ESCALA. FONTE: AUTOR, 2015. Quanto `as cores usadas na simbologia, primeiramente define-se para as feições que compõe o fundo do mapa, os quais são a malha viária e a malha municipal, nos quais usam-se cores de valor de intensidade menor. A malha viária é passível de ser desligada a fim de diminuir a quantidade de informação. Os fluxos tem suas cores definidas de maneira nominal no qual representa o produtor ou a central (dependendo da escala de visualização) no qual o produto é produzido. Tal opção de representação é justificada pelo fato de serem os produtores os responsáveis pelo transporte e por consequência tem mais interesse em consultar a origem e destino dos produtos. As entidades, as centrais e os produtores usam cores neutras como o branco e o cinza a fim de distinguir-se das demais feições. O quadro 11 apresenta uma síntese do que foi descrito.
36 Dado processado
Atributo representado (unidade)
Formato/Tamanho
Cor do preenchim ento (RGB)
Cor da borda (RGB)
Produtores
Produto - quantidade produzida (Kg)
Circulo, tamanho variável conforme o valor do atributo
255, 255, 255
0, 0, 0
Entidades
Produto - quantidade Circulo, tamanho demandada atendida variável conforme o (Kg) valor do atributo
255, 255, 0
255, 255, 255
Centrais
Produto - quantidade produzida (Kg)
Circulo, tamanho 255,255,2 variável conforme o 55 valor do atributo
Fluxo Produtor Produto – quantidade Tamanho variável - Entidade (Kg) conforme o valor do atributo Fluxo Produtor - Entidade
Nome do Produtor
-
Fluxo Central - Produto – quantidade Tamanho variável Entidade (Kg) conforme o valor do atributo
0, 0, 0
-
-
Variável conforme o produtor
-
-
-
Fluxo Central Entidade
Nome do Produtor
-
Variável conforme o produtor
-
Malha Municipal
-
-
241, 244, 199
175, 179, 138
Malha viária
-
-
255, 127, 127 QUADRO 11: REPRESENTAÇÃO DOS DADOS A SEREM APRESENTADOS CONFORME O FORMATO, TAMANHO E COR. FONTE: AUTOR, 2015. Para representar a quantidade de produto por fluxo foi definida a largura das linhas a partir da equação 1. A relação visual entre a largura da linha e a quantidade de produto é proporcional. Além disso, foi definido o valor do denominador na divisão da quantidade de produto a fim de representar um fluxo de maior valor (45000 kg) em uma feição com menos de 20 mm de largura. Largura da linha = Quantidade de produto * 20 / 45000
(1)
Para representar a quantidade de produto produzido nos produtores ou nas
37 centrais e a quantidade demandada nas entidades é definida pela relação entre a quantidade de produto (Kg) e a área do circulo, tal como na equação 2. A mesma equação contempla o valor de raio máximo para esse tipo de feição (20 mm) para a feição que representa o maior valor (75000 kg). Raio do circulo = Raiz(Quantidade de produto * PI * 20^2 / 75000)
(2)
Com a simbologia definida, a próxima etapa consiste na implementação dos rótulos e de suas regras para a visualização no mapa. Assim, os rótulos seguem um padrão de fonte, além de possuírem uma escala máxima e mínima para a visualização, a fim de melhorar a leitura do mapa. Os detalhes podem ser consultados no quadro 12.
Dado processado
Atributo representado (unidade)
Fonte
Tamanho
Escala Mínima
Escala Máxima
Produtores
Nome do Produtor
Arial
6
1:100000
1:10000
Entidades
Nome da Entidade
Arial
6
1:300000
1:10000
Centrais
Nome da Central
Arial
6
1:300000
1:100000
Fluxo Produtor Entidade
Produto – quantidade (Kg)
Arial
5
1:100000
1:10000
1:300000
1:100000
Fluxo Produto – Arial 5 Central quantidade Entidade (Kg) QUADRO 12: REPRESENTAÇÕES DOS RÓTULOS. FONTE: AUTOR, 2015.
38 5 RESULTADOS 5.1 BANCO DE DADOS A implementação do banco de dados consistiu na execução dos códigos SQLs, apresentados nos apêndices 1 a 6, na interface do PgAdmin 3. Os códigos foram baseados no diagrama de classe descrito no capitulo 4.3.4. 5.2 INTERFACE No que tange a interface de coleta de dados, o desenvolvimento consistiu na implementação de todos os itens definidos no capitulo 4.3.5. As figuras 9 a 13 trazem o resultados para as abas de inserção (lado direito da interface) de dados e sua respectiva aba sincronizada na aba de dados de entrada (lado esquerdo da interface).
FIGURA 9 – ABAS DE INSERIR DADOS DAS CENTRAIS. FONTE: AUTOR, 2015.
39
FIGURA 10 – ABAS DE INSERIR DADOS DOS PRODUTORES. FONTE: AUTOR, 2015.
FIGURA 11 – ABAS DE INSERIR DADOS DOS PRODUTOS DOS PRODUTORES. FONTE: AUTOR, 2015.
40
FIGURA 12 – ABAS DE INSERIR DADOS DAS ENTIDADES. FONTE: AUTOR, 2015.
FIGURA 13 – ABAS DE INSERIR DADOS DOS PRODUTOS DAS ENTIDADES. FONTE: AUTOR, 2015. Quanto a edição de dados, as figuras 14 a 18 apresentam as interfaces desenvolvidas para tal.
41
FIGURA 14 – ABAS DE EDITAR DADOS DAS CENTRAIS. FONTE: AUTOR, 2015.
FIGURA 15 – ABAS DE EDITAR DADOS DOS PRODUTORES. FONTE: AUTOR, 2015.
42
FIGURA 16 – ABAS DE EDITAR DADOS DOS PRODUTOS DOS PRODUTORES. FONTE: AUTOR, 2015.
FIGURA 17 – ABAS DE EDITAR DADOS DAS ENTIDADES. FONTE: AUTOR, 2015.
43
FIGURA 18 – ABAS DE EDITAR DADOS DOS PRODUTOS DAS ENTIDADES. FONTE: AUTOR, 2015. As figuras do 19 ao 25 apresentam as interfaces para as abas de apresentação dos dados processados.
FIGURA 19 – ABAS DOS RELATORIOS DOS PRODUTOS. FONTE: AUTOR, 2015.
44
FIGURA 20 – ABAS DOS RELATORIOS DO FLUXO PRODUTORES → ENTIDADES POR PRODUTOS. FONTE: AUTOR, 2015.
FIGURA 21 – ABAS DOS RELATORIOS DO FLUXO PRODUTORES → ENTIDADES. FONTE: AUTOR, 2015.
45
FIGURA 22 – ABAS DOS RELATORIOS DO FLUXO CENTRAIS → ENTIDADES. FONTE: AUTOR, 2015.
FIGURA 23 – ABAS DOS RELATORIOS DOS PRODUTOS POR PRODUTORES. FONTE: AUTOR, 2015.
46
FIGURA 24 – ABAS DOS RELATORIOS DOS PRODUTOS POR ENTIDADES. FONTE: AUTOR, 2015.
FIGURA 25 – ABAS DOS RELATORIOS DOS PRODUTOS-CENTRAIS. FONTE: AUTOR, 2015.
47 5.3 MAPAS TEMÁTICOS Para a apresentação dos resultados para os mapas temáticos gerou-se um conjunto de amostras de imagens para varias escalas. A figura 26 traz uma amostra na escala de 1:25000 mostrando as camadas da malha municipal, malha viária, além dos produtores, entidade e o fluxos entre os mesmos. Neste escala a visualização dos fluxos tornam-se complicados. A figura 27 mostra a mesma escala, contudo a camada dos produtores tem apenas um produtor selecionado, assim facilitando a visualização dos fluxos. A solução é interessante, dado que cada produtor tem o interesse primário em visualizar os fluxos advindos de sua propriedade.
FIGURA 26 – INTERFACE DO MAPA PARA A ESCALA DE 1:25000. FONTE: AUTOR, 2015.
48
FIGURA 27 – INTERFACE DO MAPA PARA A ESCALA DE 1:25000 COM SELEÇÃO DE APENAS UM PRODUTOR. FONTE: AUTOR, 2015.
49 A partir da escala de 1:100000 opta-se por apresentar os fluxos entre as centrais (agregados dos produtores) para as entidades e as suas informações relativas. A decisão provocou uma melhora na representação geral, como pode ser vista na figura 28.
FIGURA 28 – INTERFACE DO MAPA PARA A ESCALA DE 1:100000. FONTE: AUTOR, 2015.
50 Na escala 250000 começam a haver a necessidade de seleção das informações para visualização, como visto na figura 29.
FIGURA 29 – INTERFACE DO MAPA PARA A ESCALA DE 1:250000. FONTE: AUTOR, 2015. Assim, as figuras 30 e 31 mostram esse tipo de tratamento, onde apenas os fluxos de uma mesma central são visualizados.
51
FIGURA 30 – INTERFACE DO MAPA PARA A ESCALA DE 1:250000 COM SELEÇÃO UMA CENTRAL. FONTE: AUTOR, 2015.
FIGURA 31 – INTERFACE DO MAPA PARA A ESCALA DE 1:250000 COM SELEÇÃO UMA CENTRAL. FONTE: AUTOR, 2015.
52 A partir da escala de 1:500000 a visualização torna-se poluída (figura 32 e 33), sendo que na escala de 1:300000 não ha mais rótulos no mapa e na escala 1:3000000 apenas visualiza-se a malha municipal.
FIGURA 32 – INTERFACE DO MAPA PARA A ESCALA DE 1:500000. FONTE: AUTOR, 2015.
53
FIGURA 33 – INTERFACE DO MAPA PARA A ESCALA DE 1:1000000. FONTE: AUTOR, 2015.
54 6 CONCLUSÃO O desenvolvimento do sistema logístico possibilita o acesso do publico alvo a uma ferramenta de planejamento. Assim, o seu desenvolvimento deu-se de maneira a cumprir essa função da melhor maneira possível para a tecnologia e o tempo disponível. Contudo algumas limitações ainda são visíveis. A falta de dados espacias para a malha viária no OpenStreetMap ainda impede a reaplicação deste sistema em outras regiões do Brasil. Além disso, são justamente os pequenos municípios e as zonas rurais que possuem os maiores deficit de informação espacial. Assim, de forma a viabilizar a produção desta informação é importante envolver os governos locais e as comunidades que vão ser beneficiadas por uma melhor gestão do seu espaço, no caso pelo sistema logístico, a contribuir com o mapeamento da própria região, como explanado em Camboim et al (2015). Outro ponto fundamental para o desenvolvimento deste sistema logístico e o estudo de metodologias para o tema logística quando trata-se do perfil do estudo de caso apresentado. As soluções logísticas propostas em Ballou (1997) não atendem a caso de estudo de maneira satisfatória. Tal autor explora casos que envolvem a instalação de plantas industriais ou de armazéns ou a roteirização de redes de distribuição onde os dados de produção e de consumo são conhecidos. No caso deste trabalho, num primeiro momento não são definidos o valor a ser produzido, mas somente o que vai ser produzido. Quanto a coleta de dados dos produtores, entidades e centrais, sobretudo das coordenadas, faz-se atrativo o uso de dispositivos moveis. Assim, haveriam menores ocorrências de erros e proveria uma visita mais dinâmica aos locais, por não necessitar mais do transporte de computadores ou a anotação em papel. O uso de dispositivos moveis aumentaria a necessidade de comunicação entre dispositivos, contudo facilitaria a comunicação com o banco de dados e de maneira descentralizada. É interessante o desenvolvimento de soluções standalone a fim de facilitar o uso da ferramenta, principalmente quando envolve-se os mapas e os elementos associados. A usabilidade seria facilitada com o uso dos mapas em conjunto com as tabelas em uma única interface, assim haveria uma interpretação da informação de maneira mais rápida e fácil ao usuário.
55 A confecção do sistema logístico com a metodologia usada e no tempo disponibilizado ainda apresenta-se limitado quanto as versatilidades que a desenvolvimento de um plugin pode ter, havendo a necessidade de maiores estudos sobre o desenvolvimento do mesmo, explorando o uso de janelas múltiplas, tabelas dinâmicas entre outros funcionalidades possíveis. Contudo, ha pouco material disponível para tutorar, principalmente para o uso de plugins com comunicação com banco de dados. Os mapas temáticos desenvolvidos precisam, primeiramente, de estudos sobre a representação cartográfica de fluxos de transporte que mostrem-se mais adequado quando trata-se de quantidade de informação representada. Os mapas existentes possuem muitos problemas de representação. A possibilidade de selecionar a informação por interesse do usuário ou por escala, como apresentado nos resultados, pode ser uma solução a este problema. Portanto, é de interesse um estudo nesta tópico. Por fim, o que foi implementado deve ser testado in loco, pois é necessário validar o que foi desenvolvido até o momento a fim de ajustar o que foi construído ou replanejar o próprio sistema em sua concepção. Em caso de validação do sistema logístico, a reaplicação, dentro do possível, deve ocorrer de maneira a agregar caso de uso distintos e incorporar novas variáveis ao problema proposto.
56 REFERENCIAS BIBLIOGRAFICAS BALLOU, Ronald H. Business logistics: importance and some research opportunities. Gestão & produção, v. 4, n. 2, p. 117-129, 1997. CAMBOIM, Silvana Philippi; BRAVO, João Vitor Meza; SLUTER, Claudia Robbi. An Investigation into the Completeness of, and the Updates to, OpenStreetMap Data in a Heterogeneous Area in Brazil. ISPRS International Journal of Geo-Information, v. 4, n. 3, p. 1366-1388, 2015. CENTRAIS DE ABASTECIMENTO DO PARANA (CEASA). Comercialização de Frutas e Hortaliças. Curitiba: Ceasa, 2015.
Calendário de
CHAMBERLIN, Donald D. et al. A history and evaluation R.Communications of the ACM, v. 24, n. 10, p. 632-646, 1981.
of
System
CONAB. Agricultura Familiar. Companhia Nacional de Abastecimento, 2015. Disponível em: Acesso em: Dezembro de 2015 CONAB. PAA Net [Programa de Computador]. Companhia Nacional de Abastecimento, 2015. CONAB. Manual Operativo do Programa de Aquisição de Alimentos. Companhia Nacional de Abastecimento, 2014. CRAMPTON, Jeremy W.; KRYGIER, John. Uma introdução à cartografia crítica. Cartografias sociais e território. Rio de Janeiro: IPPUR/UFRJ, p. 85-111, 2008. DOWBOR, Ladislau. Sistema local de informação e cidadania. Tecnologia Social: uma estratégia para o desenvolvimento. Rio de Janeiro: Fundação Banco do Brasil, 2004. GNOME. Gedit. GNOME, 2015. Disponível em: Acessado em: Dezembro de 2015. INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATISTICA (IBGE). Censo Demográfico de 2010. Rio de Janeiro, 2010. INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATISTICA (IBGE). Malha Municipal 1:250000. IBGE, 2015. Disponível em Acesso em: Janeiro de 2015. INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATISTICA (IBGE). Perguntas mais frequentes. IBGE, 2015. Disponível em Acesso em: Dezembro de 2015.
57 INSTITUTO PARANAENSE DE DESENVOLVIMENTO ECONOMICO E SOCIAL (IPARDES). Território do Ribeira. IPARDES, 2007. Disponível em: Acesso em: Dezembro de 2015. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). ISO 19125. ISO, 2015. Disponível em: Acesso em: Dezembro de 2015. OPENSTREETMAP. OpenStreetMap. OpenStreetMap, 2015. Disponível em: Acesso em: Outubro de 2015. OPENSTREETMAP. Zoom Levels. OpenStreetMap, 2015. Disponível em: Acesso em: Novembro de 2015. OSGEO. QGIS. OSGEO, 2015 Disponível em: Acesso em: Marco de 2015. OTERO, Martina R.; JARDIM, Fabiana Alves. Reflexões sobre a construção do conceito de tecnologia social. ITS–Instituto de Tecnologia Social. s/d, 2004. PGROUTING. PgRouting. PgRouting, 2015 Disponível em: Acesso em: Agosto de 2015. PSYCOPG. Psycopg. PSYCOPG, 2015. Disponível em: Acesso em: Dezembro de 2015. PYTHON. Python, sobre. Python, 2015 Acesso em: Agosto de 2015.
Disponível
em:
QGIS. Introduction PyQGIS. QGIS, 2015. Disponível em: Acesso em: Dezembro de 2015. QGIS. Plugin: Plugin Builder. QGIS, 2015. Disponível em: Acesso em: Dezembro de 2015. QT. QT. QT, 2015 Disponível em: Acesso em:Novembro de 2015. SHEPPARD, Eric et al. Geographies of the information society. International journal of geographical information science, v. 13, n. 8, p. 797-823, 1999. SLOCUM, Terry A. Thematic cartography and geovisualization. Prentice hall, 2009. VERDEJO, Miguel Expósito. Diagnóstico rural participativo: guia prático DRP. Ministério do Desenvolvimento Agrário, Secretaria da Agricultra Familiar, 2007. VINHAS, Lúbia; QUEIROZ, GR de. Bancos de dados geográficos. Curitiba: MundoGEO, 2005.
58 APÊNDICES APÊNDICE 1 – Código para criação da tabela central..............................................56 APÊNDICE 2 – Código para criação da tabela produtor............................................57 APÊNDICE 3 – Código para criação da tabela entidade...........................................58 APÊNDICE 4 – Código para criação da tabela produto.............................................59 APÊNDICE 5 – Código para criação da tabela produto produzido............................60 APÊNDICE 6 – Código para criação da tabela produto demandado.........................61
59 APÊNDICE 1 – Código para criação da tabela central. -- Table: central -- DROP TABLE central; CREATE TABLE central ( id_central serial NOT NULL, nome_central text, lat_central double precision, long_central double precision, geom_central geometry, CONSTRAINT central_pkey PRIMARY KEY (id_central) ) WITH ( OIDS=FALSE ); ALTER TABLE central OWNER TO postgresql94;
60 APÊNDICE 2 – Código para criação da tabela produtor. -- Table: produtor -- DROP TABLE produtor; CREATE TABLE produtor ( nome_produtor text, lat_produtor double precision, long_produtor double precision, geom_produtor geometry, id_produtor serial NOT NULL, id_central integer, CONSTRAINT produtor_pkey PRIMARY KEY (id_produtor), CONSTRAINT produtor_id_central_fkey FOREIGN KEY (id_central) REFERENCES central (id_central) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) WITH ( OIDS=FALSE ); ALTER TABLE produtor OWNER TO postgresql94;
61 APÊNDICE 3 – Código para criação da tabela entidade. -- Table: entidade -- DROP TABLE entidade; CREATE TABLE entidade ( nome_entidade text, lat_entidade double precision, long_entidade double precision, geom_entidade geometry, id_entidade serial NOT NULL, CONSTRAINT entidade_pkey PRIMARY KEY (id_entidade) ) WITH ( OIDS=FALSE ); ALTER TABLE entidade OWNER TO postgresql94;
62 APÊNDICE 4 – Código para criação da tabela produto. -- Table: produto -- DROP TABLE produto; CREATE TABLE produto ( nome_produto text, preco_produto money, distancia double precision, id_produto serial NOT NULL, CONSTRAINT produto_pkey PRIMARY KEY (id_produto) ) WITH ( OIDS=FALSE ); ALTER TABLE produto OWNER TO postgresql94;
63 APÊNDICE 5 – Código para criação da tabela produto produzido. -- Table: produto_produzido -- DROP TABLE produto_produzido; CREATE TABLE produto_produzido ( id_produzido serial NOT NULL, id_produtor integer, id_produto integer, tipo_produzido boolean, tipo_potencial boolean, data_inicio_produzido date, data_fim_produzido date, CONSTRAINT produto_produzido_pkey PRIMARY KEY (id_produzido), CONSTRAINT produto_produzido_id_produto_fkey FOREIGN KEY (id_produto) REFERENCES produto (id_produto) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT produto_produzido_id_produtor_fkey FOREIGN KEY (id_produtor) REFERENCES produtor (id_produtor) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) WITH ( OIDS=FALSE ); ALTER TABLE produto_produzido OWNER TO postgresql94;
64 APÊNDICE 6 – Código para criação da tabela produto demandado. -- Table: produto_demandado -- DROP TABLE produto_demandado; CREATE TABLE produto_demandado ( id_demandado serial NOT NULL, id_entidade integer, id_produto integer, quant_demandado integer, data_inicio_demandado date, data_fim_demandado date, CONSTRAINT produto_demandado_pkey PRIMARY KEY (id_demandado), CONSTRAINT produto_demandado_id_entidade_fkey FOREIGN KEY (id_entidade) REFERENCES entidade (id_entidade) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT produto_demandado_id_produto_fkey FOREIGN KEY (id_produto) REFERENCES produto (id_produto) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) WITH ( OIDS=FALSE ); ALTER TABLE produto_demandado OWNER TO postgresql94;
Lihat lebih banyak...
Comentários
